From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> To: Rusty Russell <rusty@rustcorp.com.au> Cc: David Miller <davem@davemloft.net>, 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 <christoph@lameter.com>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Martin Bligh <mbligh@google.com> Subject: Re: local_add_return Date: Thu, 18 Dec 2008 22:35:14 -0500 [thread overview] Message-ID: <20081219033514.GA7162@Krystal> (raw) In-Reply-To: <200812190922.57629.rusty@rustcorp.com.au> * Rusty Russell (rusty@rustcorp.com.au) wrote: > On Wednesday 17 December 2008 10:31:55 Mathieu Desnoyers wrote: > > I think we have two different use-cases here : > > > > - local_t is useful as-is for things such as a tracer, which need to > > modify an element of data atomically wrt local interrupts. The > > atomic_long_t, in this case, is the correct fallback. > > - local_count_t could be used for fast counters. > > Hi Mathieu, > > Complete agreement. > > I guess I'm biassed towards local_t == counter version, something else > == nmi-safe version because that's what it was originally. Looking through > the tree, there are only 5 users: module, dmaengine and percpu_counter want > a counter, and tracing and x86 nmi.c want nmi-safe. There are several other > places I know of which want local_t-the-counter. > > I'll prepare a patch which adds nmi_safe_t, and see how it looks. There's > no amazing hurry on this, so I won't race to hit the merge window. > OK, But can we turn what you call "nmi_safe_t" into "local_atomic_t" then ? Because we have to specify that this type must only be used as part of per-cpu data with preemption disabled, and we also specify that it is atomic. Plus, nmi_safe_t does not make much sense on architectures without NMIs, where we sometimes disable interrupts to make the modification "atomic" wrt all other interrupts that can happen. Mathieu > Thanks! > Rusty. -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> To: Rusty Russell <rusty@rustcorp.com.au> Cc: David Miller <davem@davemloft.net>, 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 <christoph@lameter.com>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, Martin Bligh <mbligh@google.com> Subject: Re: local_add_return Date: Fri, 19 Dec 2008 03:35:14 +0000 [thread overview] Message-ID: <20081219033514.GA7162@Krystal> (raw) In-Reply-To: <200812190922.57629.rusty@rustcorp.com.au> * Rusty Russell (rusty@rustcorp.com.au) wrote: > On Wednesday 17 December 2008 10:31:55 Mathieu Desnoyers wrote: > > I think we have two different use-cases here : > > > > - local_t is useful as-is for things such as a tracer, which need to > > modify an element of data atomically wrt local interrupts. The > > atomic_long_t, in this case, is the correct fallback. > > - local_count_t could be used for fast counters. > > Hi Mathieu, > > Complete agreement. > > I guess I'm biassed towards local_t = counter version, something else > = nmi-safe version because that's what it was originally. Looking through > the tree, there are only 5 users: module, dmaengine and percpu_counter want > a counter, and tracing and x86 nmi.c want nmi-safe. There are several other > places I know of which want local_t-the-counter. > > I'll prepare a patch which adds nmi_safe_t, and see how it looks. There's > no amazing hurry on this, so I won't race to hit the merge window. > OK, But can we turn what you call "nmi_safe_t" into "local_atomic_t" then ? Because we have to specify that this type must only be used as part of per-cpu data with preemption disabled, and we also specify that it is atomic. Plus, nmi_safe_t does not make much sense on architectures without NMIs, where we sometimes disable interrupts to make the modification "atomic" wrt all other interrupts that can happen. Mathieu > Thanks! > Rusty. -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2008-12-19 3:35 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-12-15 13:47 local_add_return Steven Rostedt 2008-12-16 6:33 ` local_add_return Rusty Russell 2008-12-16 6:57 ` local_add_return David Miller 2008-12-16 7:13 ` local_add_return David Miller 2008-12-16 22:38 ` local_add_return Rusty Russell 2008-12-16 22:50 ` local_add_return Rusty Russell 2008-12-16 23:25 ` local_add_return Luck, Tony 2008-12-16 23:25 ` local_add_return Luck, Tony 2008-12-16 23:43 ` local_add_return Heiko Carstens 2008-12-16 23:43 ` local_add_return Heiko Carstens 2008-12-16 23:59 ` local_add_return Eric Dumazet 2008-12-16 23:59 ` local_add_return Eric Dumazet 2008-12-17 0:01 ` local_add_return Mathieu Desnoyers 2008-12-17 0:01 ` local_add_return Mathieu Desnoyers 2008-12-18 22:52 ` local_add_return Rusty Russell 2008-12-18 22:53 ` local_add_return Rusty Russell 2008-12-19 3:35 ` Mathieu Desnoyers [this message] 2008-12-19 3:35 ` local_add_return Mathieu Desnoyers 2008-12-19 5:54 ` local_add_return Rusty Russell 2008-12-19 5:54 ` local_add_return Rusty Russell 2008-12-19 17:06 ` local_add_return Mathieu Desnoyers 2008-12-19 17:06 ` local_add_return Mathieu Desnoyers 2008-12-20 1:33 ` local_add_return Rusty Russell 2008-12-20 1:45 ` local_add_return Rusty Russell 2008-12-20 1:33 ` local_add_return Rusty Russell 2008-12-22 18:43 ` local_add_return Mathieu Desnoyers 2008-12-22 18:43 ` local_add_return Mathieu Desnoyers 2008-12-24 11:42 ` local_add_return Rusty Russell 2008-12-24 11:54 ` local_add_return Rusty Russell 2008-12-24 18:53 ` local_add_return Mathieu Desnoyers 2008-12-24 18:53 ` local_add_return Mathieu Desnoyers 2008-12-16 16:25 ` local_add_return Mathieu Desnoyers 2008-12-17 11:23 ` local_add_return Rusty Russell
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20081219033514.GA7162@Krystal \ --to=mathieu.desnoyers@polymtl.ca \ --cc=akpm@linux-foundation.org \ --cc=benh@kernel.crashing.org \ --cc=christoph@lameter.com \ --cc=davem@davemloft.net \ --cc=linux-ia64@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-s390@vger.kernel.org \ --cc=mbligh@google.com \ --cc=paulmck@linux.vnet.ibm.com \ --cc=paulus@samba.org \ --cc=rostedt@goodmis.org \ --cc=rusty@rustcorp.com.au \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.