Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763562AbZAOSk1 (ORCPT ); Thu, 15 Jan 2009 13:40:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759247AbZAOSkL (ORCPT ); Thu, 15 Jan 2009 13:40:11 -0500 Received: from mx2.mail.elte.hu ([157.181.151.9]:37677 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759228AbZAOSkJ (ORCPT ); Thu, 15 Jan 2009 13:40:09 -0500 Date: Thu, 15 Jan 2009 19:39:42 +0100 From: Ingo Molnar To: Andrew Morton Cc: Tejun Heo , "H. Peter Anvin" , Brian Gerst , ebiederm@xmission.com, cl@linux-foundation.org, rusty@rustcorp.com.au, travis@sgi.com, linux-kernel@vger.kernel.org, steiner@sgi.com, hugh@veritas.com Subject: Re: [PATCH] percpu: add optimized generic percpu accessors Message-ID: <20090115183942.GA6325@elte.hu> References: <496F0F50.6070200@kernel.org> <20090115113045.GG22850@elte.hu> <496F2032.5080502@kernel.org> <20090115122611.GJ22850@elte.hu> <496F346B.6020804@kernel.org> <20090115130740.GE21839@elte.hu> <496F38C7.5000403@kernel.org> <20090115093007.4215b4b4.akpm@linux-foundation.org> <20090115180259.GJ22472@elte.hu> <20090115103406.a85968f0.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090115103406.a85968f0.akpm@linux-foundation.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2423 Lines: 66 * Andrew Morton wrote: > On Thu, 15 Jan 2009 19:02:59 +0100 Ingo Molnar wrote: > > > > > * Andrew Morton wrote: > > > > > On Thu, 15 Jan 2009 22:23:19 +0900 Tejun Heo wrote: > > > > > > > --- a/include/asm-generic/percpu.h > > > > +++ b/include/asm-generic/percpu.h > > > > @@ -80,4 +80,56 @@ extern void setup_per_cpu_areas(void); > > > > #define DECLARE_PER_CPU(type, name) extern PER_CPU_ATTRIBUTES \ > > > > __typeof__(type) per_cpu_var(name) > > > > > > > > +/* > > > > + * Optional methods for optimized non-lvalue per-cpu variable access. > > > > + * > > > > + * @var can be a percpu variable or a field of it and its size should > > > > + * equal char, int or long. percpu_read() evaluates to a lvalue and > > > > + * all others to void. > > > > + * > > > > + * These operations are guaranteed to be atomic w.r.t. preemption. > > > > + * The generic versions use plain get/put_cpu_var(). Archs are > > > > + * encouraged to implement single-instruction alternatives which don't > > > > + * require preemption protection. > > > > + */ > > > > +#ifndef percpu_read > > > > +# define percpu_read(var) \ > > > > + ({ \ > > > > + typeof(per_cpu_var(var)) __tmp_var__; \ > > > > + __tmp_var__ = get_cpu_var(var); \ > > > > + put_cpu_var(var); \ > > > > + __tmp_var__; \ > > > > + }) > > > > +#endif > > > > > > I wonder if the preempt_disable()/preempt_enable() in here actually > > > does anything useful on any architecture. > > > > Provides "this is IRQ safe" > > ? > > > and "this is preempt safe" semantics. > > Of course. But do any architectures actually _need_ that for a single > read? not for a read i guess - but for the other ops like add/and/or/xor. > Maybe. And if so, they can interpose their arch-specific > implementation. But if the generic version is optimal for them, they > wouldn't need to.. we cannot turn the generic ops into a single instruction so arch methods are preferable no matter how thick or thin the generic version is. But i agree that the optimization you suggest could be done. Ingo -- 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/