Re: [PATCH 5/6] net: __this_cpu_inc in route.c

2013-10-16 Thread Christoph Lameter
On Wed, 16 Oct 2013, Peter Zijlstra wrote: > For x86 its fairly easy to see its correct this way; but for load-store > archs this isn't immediately obvious to me. > > Suppose; r1 contains our per-cpu pointer: > > LOAD r2, per-cpu-base > ADD r1, r2 > LOAD r2, $(r1) # load valu

Re: [PATCH 5/6] net: __this_cpu_inc in route.c

2013-10-16 Thread Peter Zijlstra
On Wed, Oct 16, 2013 at 02:22:49AM -0700, Eric Dumazet wrote: > On Wed, 2013-10-16 at 10:46 +0200, Peter Zijlstra wrote: > > > Are we sure all !x86 implementations will DTRT in that it will increment > > some CPU and not get horribly confused? I suppose it would; but is > > that a guarantee given

Re: [PATCH 5/6] net: __this_cpu_inc in route.c

2013-10-16 Thread Eric Dumazet
On Wed, 2013-10-16 at 10:46 +0200, Peter Zijlstra wrote: > Are we sure all !x86 implementations will DTRT in that it will increment > some CPU and not get horribly confused? I suppose it would; but is > that a guarantee given someplace? I think we should be fine, these are only stats exposed on /

Re: [PATCH 5/6] net: __this_cpu_inc in route.c

2013-10-16 Thread Peter Zijlstra
On Tue, Oct 15, 2013 at 12:47:27PM -0500, Christoph Lameter wrote: > The RT_CACHE_STAT_INC macro triggers the new preemption checks > for __this_cpu ops > > I do not see any other synchronization that would allow the use > of a __this_cpu operation here however in commit > dbd2915ce87e811165da0717

[PATCH 5/6] net: __this_cpu_inc in route.c

2013-10-15 Thread Christoph Lameter
The RT_CACHE_STAT_INC macro triggers the new preemption checks for __this_cpu ops I do not see any other synchronization that would allow the use of a __this_cpu operation here however in commit dbd2915ce87e811165da0717f8e159276ebb803e Andrew justifies the use of raw_smp_processor_id() here becaus

[PATCH 5/6] net: __this_cpu_inc in route.c

2013-10-11 Thread Christoph Lameter
The RT_CACHE_STAT_INC macro triggers the new preemption checks for __this_cpu ops I do not see any other synchronization that would allow the use of a __this_cpu operation here however in commit dbd2915ce87e811165da0717f8e159276ebb803e Andrew justifies the use of raw_smp_processor_id() here becaus