[BUG] 2.6.37-rc3 massive interactivity regression on ARM

[eric.dumazet@gmail.com (Eric Dumazet)]

Le vendredi 10 d?cembre 2010 ? 15:09 -0600, Christoph Lameter a ?crit :
> On Fri, 10 Dec 2010, Eric Dumazet wrote:
> 
> >
> > By the way, we need smp_wmb(), not barrier(), even only the "owner cpu"
> > can write into its 'percpu' seqcount.
> >
> > There is nothing special about a seqcount being percpu or a 'global'
> > one. We must have same memory barrier semantics.
> 
> There is certainly a major difference in that execution of a stream of
> instructions on the same cpu is guaranteed to have a coherent view of
> the data. That is not affected by interrupts etc.
> 

We dont care of interrupts. We care of doing a transaction over a
complex set of data, that cannot be done using an atomic op (or we need
a spinlock/mutex/rwlock), and should not because of performance.

> >
> > 	this_cpu_write_seqcount_begin(&myseqcount);
> > 	this_cpu_add(mydata1, add1);
> > 	this_cpu_add(mydata2, add2);
> > 	this_cpu_inc(mydata3);
> > 	this_cpu_write_seqcount_end(&myseqcount);
> >
> > We protect the data[1,2,3] set with a seqcount, so need smp_wmb() in
> > both _begin() and _end()
> 
> There is nothing to protect there since processing is on the same cpu. The
> data coherency guarantees of the processor will not allow anything out of
> sequence to affect execution. An interrupt f.e. will not cause updates to
> mydata1 to get lost.
> 

Please take a look at include/linux/u64_stats_sync.h, maybe you'll
understand the concern about using a seqcount to protect a set of data,
for example a 256 bit counter increment.