Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932323AbZDBDeN (ORCPT ); Wed, 1 Apr 2009 23:34:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753410AbZDBDdy (ORCPT ); Wed, 1 Apr 2009 23:33:54 -0400 Received: from smtp.ultrahosting.com ([74.213.174.254]:40635 "EHLO smtp.ultrahosting.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761423AbZDBDdv (ORCPT ); Wed, 1 Apr 2009 23:33:51 -0400 Date: Wed, 1 Apr 2009 23:28:44 -0400 (EDT) From: Christoph Lameter X-X-Sender: cl@qirst.com To: Ingo Molnar cc: Matthew Wilcox , Linus Torvalds , Tejun Heo , Martin Schwidefsky , rusty@rustcorp.com.au, tglx@linutronix.de, x86@kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com, Paul Mundt , rmk@arm.linux.org.uk, starvik@axis.com, ralf@linux-mips.org, davem@davemloft.net, cooloney@kernel.org, kyle@mcmartin.ca, grundler@parisc-linux.org, takata@linux-m32r.org, benh@kernel.crashing.org, rth@twiddle.net, ink@jurassic.park.msu.ru, heiko.carstens@de.ibm.com, Nick Piggin , Peter Zijlstra Subject: Re: [PATCH UPDATED] percpu: use dynamic percpu allocator as the default percpu allocator In-Reply-To: <20090402032506.GC21545@elte.hu> Message-ID: References: <49D2B209.9060000@kernel.org> <20090401154913.GA31435@elte.hu> <20090401190113.GA734@elte.hu> <20090401223241.GA28168@elte.hu> <20090401225754.GN8014@parisc-linux.org> <20090402021024.GA26446@elte.hu> <20090402032506.GC21545@elte.hu> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 975 Lines: 29 On Thu, 2 Apr 2009, Ingo Molnar wrote: > You didnt really answer to my suggestion(s) though. You only stated > that: > > "problem XYZ is something normal that comes with the cpu caching > schemes. As long as there is no significant impact on > performance weare fine with it." > > Which i'd proffer is true for any given value of XYZ ;-) Nope. If XYZ is a significant performance issue then we are not fine with XYZ. __read_mostly was introduced to deal with signficant false aliasing issues. False aliasing can be set to occur anytime you place two variables in the same cacheline. That is by design in the current cacheline schemes. One would not place a variable in a separate cacheline without good reason. -- 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/