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

From: Christoph Lameter <cl@gentwo.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Tejun Heo <tj@kernel.org>, David Howells <dhowells@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] percpu: add data dependency barrier in percpu accessors and operations
Date: Thu, 19 Jun 2014 15:42:07 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.11.1406191540240.4002@gentwo.org> (raw)
In-Reply-To: <20140617194017.GO4669@linux.vnet.ibm.com>

On Tue, 17 Jun 2014, Paul E. McKenney wrote:

> > Similar in swapon(). The percpu allocation is performed before access to
> > the containing structure (via enable_swap_info).
>
> Those are indeed common use cases.  However...
>
> There is code where one CPU writes to another CPU's per-CPU variables.
> One example is RCU callback offloading, where a kernel thread (which
> might be running anywhere) dequeues a given CPU's RCU callbacks and
> processes them.  The act of dequeuing requires write access to that
> CPU's per-CPU rcu_data structure.  And yes, atomic operations and memory
> barriers are of course required to make this work.

In that case special care needs to be taken to get this right. True.

I typically avoid these scenarios by sending an IPI with a pointer to the
data structure. The modification is done by the cpu for which the per cpu
data is local.

Maybe rewrite the code to avoid writing to other processors percpu data
would be the right approach?