From: Andrew Morton <akpm@linux-foundation.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
David Miller <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Christoph Lameter <cl@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>, Andi Kleen <andi@firstfloor.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Nick Piggin <npiggin@kernel.dk>
Subject: Re: [PATCH] atomic: add atomic_inc_not_zero_hint()
Date: Fri, 5 Nov 2010 10:20:38 -0700 [thread overview]
Message-ID: <20101105102038.53e36f9e.akpm@linux-foundation.org> (raw)
In-Reply-To: <1288975980.2882.877.camel@edumazet-laptop>
On Fri, 05 Nov 2010 17:53:00 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Andrew
>
> atomic_inc_not_zero() / atomic_add_unless() ... are spreaded in many
> arch/xxx/include/asm/atomic.h, but they are generic.
>
> Apparently there is no centralization of some common atomic features...
>
> What do you think adding a new file so that we can move common
> definitions in it ?
>
> Thanks
>
> [PATCH] atomic: add atomic_inc_not_zero_hint()
>
> Followup of perf tools session in Netfilter WorkShop 2010
>
> In network stack we make high usage of atomic_inc_not_zero() in contexts
> we know the probable value of atomic before increment (2 for udp sockets
> for example)
>
> Using a special version of atomic_inc_not_zero() giving this hint can
> help processor to use less bus transactions.
>
> On x86 (MESI protocol) for example, this avoids entering Shared state,
> because "lock cmpxchg" issues an RFO (Read For Ownership)
It totally makes sense to add include/linu/atomic.h for common things.
Perhaps there's already code in arch/*/include/asm/atomic.h which
should be hoisted up there. But that can't reliably be done until a
million files have had their #includes switched :(
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Christoph Lameter <cl@linux-foundation.org>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Andi Kleen <andi@firstfloor.org>
> Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
> Cc: David Miller <davem@davemloft.net>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: Nick Piggin <npiggin@kernel.dk>
> ---
> include/linux/atomic.h | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> new file mode 100644
> index 0000000..c04327a
> --- /dev/null
> +++ b/include/linux/atomic.h
> @@ -0,0 +1,29 @@
> +#ifndef _LINUX_ATOMIC_H
> +#define _LINUX_ATOMIC_H
> +#include <asm/atomic.h>
> +
> +/**
> + * atomic_inc_not_zero_hint - increment if not null
> + * @v: pointer of type atomic_t
> + * @hint: probable value of the atomic before the increment
> + *
> + * This version of atomic_inc_not_zero() gives a hint of probable
> + * value of the atomic. This helps processor to not read the memory
> + * before doing the atomic read/modify/write cycle, lowering
> + * number of bus transactions on some arches.
> + * Note: hint MUST not be 0 !
> + */
It's quite unobvious *why* `hint' cannot be zero. Can you please add
the reasoning to the comment? Also, the local `hint' should be
referred to as "@hint" in a kerneldoc comment.
> +static inline int atomic_inc_not_zero_hint(atomic_t *v, int hint)
> +{
> + int val, c = hint;
> +
> + do {
> + val = atomic_cmpxchg(v, c, c + 1);
> + if (val == c)
> + return 1;
> + c = val;
> + } while (c);
> +
> + return 0;
> +}
Should/could this have implemented a more general
atomic_add_not_zero_hint() and made atomic_inc_not_zero_hint() a
wrapper around that?
Also, it might make sense to add "#ifndef atomic_inc_not_zero_hint"
wrappers around this function so that the arch can implement an
overriding custom version. And that becomes a general rule as more
functions are added to include/linux/atomic.h.
next prev parent reply other threads:[~2010-11-05 17:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 16:53 [PATCH] atomic: add atomic_inc_not_zero_hint() Eric Dumazet
2010-11-05 17:20 ` Andrew Morton [this message]
2010-11-05 18:00 ` Eric Dumazet
2010-11-05 18:08 ` Andrew Morton
2010-11-05 18:20 ` Eric Dumazet
2010-11-05 18:28 ` Andrew Morton
2010-11-05 19:20 ` Eric Dumazet
2010-11-05 19:39 ` Andrew Morton
2010-11-05 19:46 ` Eric Dumazet
2010-11-05 19:51 ` Paul E. McKenney
2010-11-12 19:14 ` Christoph Lameter
2010-11-13 22:26 ` Paul E. McKenney
2010-11-15 13:57 ` Christoph Lameter
2010-11-15 14:07 ` Andi Kleen
2010-11-15 14:16 ` Christoph Lameter
2010-11-15 14:17 ` Eric Dumazet
2010-11-15 14:25 ` Christoph Lameter
2010-11-15 14:39 ` Andi Kleen
2010-11-15 14:47 ` Eric Dumazet
2010-11-05 18:40 ` Paul E. McKenney
2010-11-05 19:12 ` Eric Dumazet
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=20101105102038.53e36f9e.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=acme@infradead.org \
--cc=andi@firstfloor.org \
--cc=cl@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=npiggin@kernel.dk \
--cc=paulmck@linux.vnet.ibm.com \
/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: link
Be 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.