[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200812190922.57629.rusty@rustcorp.com.au>
Date: Fri, 19 Dec 2008 09:22:56 +1030
From: Rusty Russell <rusty@...tcorp.com.au>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc: David Miller <davem@...emloft.net>, rostedt@...dmis.org,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
paulus@...ba.org, benh@...nel.crashing.org,
linux-ia64@...r.kernel.org, linux-s390@...r.kernel.org,
Christoph Lameter <christoph@...eter.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Martin Bligh <mbligh@...gle.com>
Subject: Re: local_add_return
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.
Thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists