Re: [PATCH RFC] percpu: add data dependency barrier in percpu accessors and operations

[Tejun Heo <tj@kernel.org>]

Hello, Paul.

On Tue, Jun 17, 2014 at 09:57:02AM -0700, Paul E. McKenney wrote:
> I am not sure that this is actually better than having the allocating
> CPU do the initialization, though, even given a large number of CPUs.
> Or maybe even especially given a large number of CPUs.  The bit about
> asking all the other CPUs to do their allocations and initializations
> and then waiting for them to respond might not be pretty.

If it ever happens, it'd probably be the allocator trying to keep
certain amount ready as allocation buffer with buffer refill
synchronization happening lazily in large chunks.  We don't need
anything like that at this point.  I was trying to point out that the
semantics isn't immediately clear.

> > * Add data dependency barrier to percpu accessors and write barrier to
> >   the allocator with the comment that this will be replaced with
> >   proper assignment macros and mark this change w/ -stable.
> > 
> > * Later, introduce percpu pointer assignment macros and convert all
> >   users and remove the wmb added above.
> 
> This longer-term approach seems like a good one to me.

Alright, going that way then.  This will bring percpu usages very
close to RCU, which I like.

> I much prefer the model where the thing that -published- the pointer is
> responsible for memory ordering.  After all, if a task allocates some
> zeroed memory, uses it locally, then frees it, there is no ordering
> to worry about in the first place.  The memory allocator doing the
> initialization cannot tell how the memory is to be used, after all.

Yeah, "publish" is a nice verb to put on it.  No objection.

Thanks.

-- 
tejun