Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965438AbaFSUv5 (ORCPT ); Thu, 19 Jun 2014 16:51:57 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:45879 "EHLO e34.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965016AbaFSUvx (ORCPT ); Thu, 19 Jun 2014 16:51:53 -0400 Date: Thu, 19 Jun 2014 13:51:37 -0700 From: "Paul E. McKenney" To: Christoph Lameter Cc: Tejun Heo , David Howells , Linus Torvalds , Andrew Morton , Oleg Nesterov , linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC] percpu: add data dependency barrier in percpu accessors and operations Message-ID: <20140619205137.GK4904@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20140612135630.GA23606@htj.dyndns.org> <20140617194017.GO4669@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14061920-1542-0000-0000-000002B12703 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 19, 2014 at 03:42:07PM -0500, Christoph Lameter wrote: > 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? Or just keep doing what I am doing. What exactly is the problem with it? (Other than probably needing to clean up the cache alignment of some of the per-CPU structures?) Thanx, Paul -- 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/