From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754590AbYLTBeV (ORCPT ); Fri, 19 Dec 2008 20:34:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752637AbYLTBeJ (ORCPT ); Fri, 19 Dec 2008 20:34:09 -0500 Received: from ozlabs.org ([203.10.76.45]:47652 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752326AbYLTBeI convert rfc822-to-8bit (ORCPT ); Fri, 19 Dec 2008 20:34:08 -0500 From: Rusty Russell To: Mathieu Desnoyers Subject: Re: local_add_return Date: Sat, 20 Dec 2008 12:03:50 +1030 User-Agent: KMail/1.10.3 (Linux/2.6.27-9-generic; KDE/4.1.3; i686; ; ) Cc: David Miller , rostedt@goodmis.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, paulus@samba.org, benh@kernel.crashing.org, linux-ia64@vger.kernel.org, linux-s390@vger.kernel.org, Christoph Lameter , "Paul E. McKenney" , Martin Bligh References: <200812191624.46580.rusty@rustcorp.com.au> <20081219170627.GB1339@Krystal> In-Reply-To: <20081219170627.GB1339@Krystal> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline Message-Id: <200812201203.51351.rusty@rustcorp.com.au> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday 20 December 2008 03:36:27 Mathieu Desnoyers wrote: > * Rusty Russell (rusty@rustcorp.com.au) wrote: > > Then some trace-specific typedef like "trace_counter_t" which goes to local_t > > or atomic_(long?)_t? > > > > Should be a simple patch and pretty clear. > > Hrm, is it me or linking a basic type definition to a single user seems > like the wrong approach ? Well, it's an ongoing debate. Old school kernel coders believe that infrastructure should be resisted: you implement what you need to, then if it turns out to be generically useful you put it somewhere that the second user can access it. Otherwise we end up with unused infrastructure, or overspecialized infrastructure which doesn't actually meet the general need. local_t displays both these properties. > The idea behind declaring new types is, to me, that they should describe > as generally as possible what they provide and what they are. If we > think of the future, where we might want to use such local atomic types > for other purposes than tracing, I think we will end up regretting such > specific naming scheme. I can be convinced, but I'll need more than speculation. Assuming local_long_atomic_t, can you produce a patch which uses it somewhere else? > local_atomic_long_t is a _new_ primitive, which cannot be > implemented by a trivalue and differs from atomic_long_t, on more > architectures than x86. On mips and powerpc, at least, it can be > implemented as an atomic operation without the memory barriers, which > improves performances a lot. OK, you lost me here. I don't see a memory barrier in the powerpc atomic ops. Is there an implied one I missed? > I think the following scheme would be pretty simple and yet not tied to > any specific user : > > local_long_t > - Fast per-cpu counter, not necessarily atomic. > Implements long trivalues, or uses local_atomic_long_t. > local_atomic_long_t > - Fast per-cpu atomic counter. > Implements per-cpu atomic counters or uses atomic_long_t. >>From the point of view of someone trying to decide what to use, the real difference is: use local_long_t unless you need the atomic-style operators which are only available on local_atomic_long_t, or NMI-safe behaviour. Is this correct? > We could do the same with "int" type for : > local_t > local_atomic_t > atomic_t > > If we need smaller counters. Erk... no, renaming one to two is bad enough. Changing the semantics of one and introducing three more is horrible. If we're going to rename, I'd choose local_counter_t and local_atomic_t (both long: I don't think there's a real penalty is there?). Thanks, Rusty.