[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1101211114530.15692@router.home>
Date: Fri, 21 Jan 2011 11:21:02 -0600 (CST)
From: Christoph Lameter <cl@...ux.com>
To: Tejun Heo <tj@...nel.org>
cc: "H. Peter Anvin" <hpa@...or.com>,
Pekka Enbeerg <penberg@...helsinki.fi>,
linux-kernel@...r.kernel.org,
Eric Dumazet <eric.dumazet@...il.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
akpm@...ux-foundation.org
Subject: Re: x86: A fast way to check capabilities of the current cpu
On Fri, 21 Jan 2011, Tejun Heo wrote:
> Hello, Christoph.
>
> I was trying to forward this to x86 tree but spotted a problem.
>
> On Wed, Dec 15, 2010 at 02:07:39PM -0600, Christoph Lameter wrote:
> > +static __always_inline int this_cpu_constant_test_bit(unsigned int nr,
> > + const unsigned long __percpu *addr)
> > +{
> > + unsigned long __percpu *a = (unsigned long *)addr + nr / BITS_PER_LONG;
> > +
> > + return ((1UL << (nr % BITS_PER_LONG)) & percpu_read_stable(*a)) != 0;
> > +}
>
> I don't think percpu_read_stable() can be used here. It's not
> guaranteed to be stable across different cpus.
Why would that matter? The caller has to disabled preemption anyways since
otherwise the processor may change which means that the result of the
operation is useless.
> Also, can we just implement what's necessary on top of this_cpu_has()?
> this_cpu_has() already has constant handling, so there's no need to
> add this_cpu_test_bit() at this point.
Not sure what you mean. this_cpu_test_bit is necessary because
test_cpu_cap expects a regular pointer and performs a regular load.
this_cpu_constant_test_bit handles the segment prefix necessary for a per
cpu load.
The constant refers to the bit.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists