Re: local_add_return

[Rusty Russell <rusty@rustcorp.com.au>]

On Tuesday 16 December 2008 00:17:35 Steven Rostedt wrote:
> Shouldn't local_add_return be a way for archs that can increment a memory 
> location atomically against interrupts to use that infrastructure? It can 
> simply fall back to atomic_add_return for those archs that do not have 
> a lesser equivalent of atomic_add_return.

local_t was originally introduced (but actually never used for) the
SNMP counters.  They use two counters to avoid atomics, but as the ancient
comment says:

/* 
 * FIXME: On x86 and some other CPUs the split into user and softirq parts
 * is not needed because addl $1,memory is atomic against interrupts (but 
 * atomic_inc would be overkill because of the lock cycles). Wants new 
 * nonlocked_atomic_inc() primitives -AK
 */ 
#define DEFINE_SNMP_STAT(type, name)	\
	__typeof__(type) *name[2]

Then last year Mathieu sent (and Andrew accepted) a "rich set of atomic
operations", including excellent documentation "local_ops.txt".  Except
he thought they were atomics, so treated them accordingly.  Also, there
were no users (you're now the only one).

But if these new operations are to become the norm, it changes how archs
should implement local_t.  eg. trivalue becomes less attractive, atomic_long
more.  x86 has its own implementation so doesn't have these issues.

Now, I posted a benchmark patch before for archs to test.  I'm interested
in Sparc64.  Does any arch win from using multiple counters?  PowerPC has
soft interrupt disable, so that solution wins over atomic_long_t for them.

Cheers,
Rusty.