Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755789AbaFTPYD (ORCPT ); Fri, 20 Jun 2014 11:24:03 -0400 Received: from qmta08.emeryville.ca.mail.comcast.net ([76.96.30.80]:46209 "EHLO qmta08.emeryville.ca.mail.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753239AbaFTPYC (ORCPT ); Fri, 20 Jun 2014 11:24:02 -0400 Date: Fri, 20 Jun 2014 10:23:57 -0500 (CDT) From: Christoph Lameter To: Tejun Heo cc: "Paul E. McKenney" , 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 In-Reply-To: <20140619211543.GD9814@mtj.dyndns.org> Message-ID: References: <20140612135630.GA23606@htj.dyndns.org> <20140617194017.GO4669@linux.vnet.ibm.com> <20140619204634.GB9814@mtj.dyndns.org> <20140619211543.GD9814@mtj.dyndns.org> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Jun 2014, Tejun Heo wrote: > Again, data dependency barrier is noop in all in-use archs. A barrier limits what the compiler can do. > > Remote write events are contrary to that design and are exceedingly rare. > > An IPI is justifiable for such a rare event. At least in my use cases I > > have always found that to be sufficient. Well, I designed the data > > structures in a way that made this possible because of the design criteria > > that did not allow me remote write access to other processors per cpu > > data. > > You're repeatedly getting wayside in the discussion. What are you > suggesting? Sending IPIs on each percpu allocation? No this is about sending an IPI if you want to modify the percpu data of another process. There was a mentionig of code that modifies the per cpu data of another processor? > Again, I'm leaning towards just clarifying the init write ownership to > the allocating CPU as that seems the most straight forward way to deal > with it, but please stop brining up the raw performance thing. Nobody > is doing anything to that. It's not relevant in the discussion. Ok sounds good. -- 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/