Messages in this thread | | | Subject | Re: [BUG] 2.6.37-rc3 massive interactivity regression on ARM | From | Eric Dumazet <> | Date | Fri, 10 Dec 2010 22:22:45 +0100 |
| |
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.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |