[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091217202558.GA21713@Krystal>
Date: Thu, 17 Dec 2009 15:25:58 -0500
From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To: Christoph Lameter <cl@...ux-foundation.org>
Cc: Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org,
Mel Gorman <mel@....ul.ie>,
Pekka Enberg <penberg@...helsinki.fi>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [this_cpu_xx V7 0/8] Per cpu atomics in core allocators and
cleanup
* Christoph Lameter (cl@...ux-foundation.org) wrote:
> > However, I would need:
> >
> > this_cpu_cmpxchg(scalar, oldv, newv)
> > (maps to x86 cmpxchg)
> >
> > this_cpu_add_return(scalar, value)
> > (maps to x86 xadd)
> >
> > too. Is that a planned addition ?
>
> It was not necessary. Its easy to add though.
>
> > (while we are at it, we might as will add the xchg instruction,
> > althrough it has an implied LOCK prefix on x86).
>
> Well yeah thats a thorny one. One could use the cmpxchg instead?
Yes, although maybe it would make sense to encapsulate it in a xchg
primitive anyway, in case some architecture has a better xchg than x86.
For instance, powerpc, with its linked load/store conditional, can skip
a comparison for xchg that's otherwise required for cmpxchg.
Some quick test on my Intel Xeon E5405:
local cmpxchg: 14 cycles
xchg: 18 cycles
So yes, indeed, the non-LOCK prefixed local cmpxchg seems a bit faster
than the xchg, given the latter has an implied LOCK prefix.
Code used for local cmpxchg:
old = var;
do {
ret = cmpxchg_local(&var, old, 4);
if (likely(ret == old))
break;
old = ret;
} while (1);
Thanks,
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
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