Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755318AbZA2TQX (ORCPT ); Thu, 29 Jan 2009 14:16:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752007AbZA2TQK (ORCPT ); Thu, 29 Jan 2009 14:16:10 -0500 Received: from smtp3.ultrahosting.com ([74.213.175.254]:51145 "EHLO smtp.ultrahosting.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751785AbZA2TQJ (ORCPT ); Thu, 29 Jan 2009 14:16:09 -0500 Date: Thu, 29 Jan 2009 13:33:13 -0500 (EST) From: Christoph Lameter X-X-Sender: cl@qirst.com To: Mathieu Desnoyers cc: Rusty Russell , Tejun Heo , Ingo Molnar , Herbert Xu , akpm@linux-foundation.org, hpa@zytor.com, brgerst@gmail.com, ebiederm@xmission.com, travis@sgi.com, linux-kernel@vger.kernel.org, steiner@sgi.com, hugh@veritas.com, "David S. Miller" , netdev@vger.kernel.org Subject: Re: [PATCH] percpu: add optimized generic percpu accessors In-Reply-To: <20090128180757.GA9908@Krystal> Message-ID: References: <20090115183942.GA6325@elte.hu> <200901271213.18605.rusty@rustcorp.com.au> <497E705B.5000302@kernel.org> <200901282108.51864.rusty@rustcorp.com.au> <20090128180757.GA9908@Krystal> 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: 1176 Lines: 26 On Wed, 28 Jan 2009, Mathieu Desnoyers wrote: > > The term cpu is meaning multiple things at this point. So yes it may be > > better to go with glibc naming of thread local space. > > > > However using "local" for "per-cpu" could be confusing with the glibc > naming of thread local space, because "per-thread" and "per-cpu" > variables are different from a synchronization POV and we can end up > needing both (e.g. a thread local variable can never be accessed by > another thread, but a cpu local variable could be accessed by a > different CPU due to scheduling). gcc/glibc support a __thread attribute to variables. As far as I can tell this automatically makes gcc perform the relocation to the current context using a segment register. But its a weird ABI http://people.redhat.com/drepper/tls.pdf. After reading that I agree that we should stay with the cpu ops and forget about the local and thread stuff in gcc/glibc. -- 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/