[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <497F8F02.9000603@hp.com>
Date: Tue, 27 Jan 2009 14:47:30 -0800
From: Rick Jones <rick.jones2@...com>
To: David Miller <davem@...emloft.net>
CC: cl@...ux-foundation.org, tj@...nel.org, rusty@...tcorp.com.au,
mingo@...e.hu, herbert@...dor.apana.org.au,
akpm@...ux-foundation.org, hpa@...or.com, brgerst@...il.com,
ebiederm@...ssion.com, travis@....com,
linux-kernel@...r.kernel.org, steiner@....com, hugh@...itas.com,
netdev@...r.kernel.org, mathieu.desnoyers@...ymtl.ca,
"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>
Subject: Re: [PATCH] percpu: add optimized generic percpu accessors
David Miller wrote:
> From: Christoph Lameter <cl@...ux-foundation.org>
> Date: Tue, 27 Jan 2009 15:08:57 -0500 (EST)
>
>
>>On Tue, 27 Jan 2009, Tejun Heo wrote:
>>
>>
>>>>later). That's because they use TLB tricks for a static 64k per-cpu
>>>>area, but this doesn't scale. That might not be vital: abandoning
>>>>that trick will mean they can't optimise read_percpu/read_percpu_var
>>>>etc as much.
>>
>>Why wont it scale? this is a separate TLB entry for each processor.
>
>
> The IA64 per-cpu TLB entry only covers 64k which makes use of it for
> dynamic per-cpu stuff out of the question. That's why it "doesn't
> scale"
I was asking around, and was told that on IA64 *harware* at least, in addition to
supporting multiple page sizes (up to a GB IIRC), one can pin up to 8 or perhaps
1/2 the TLB entries.
So, in theory if one were so inclined the special pinned per-CPU entry could
either be more than one 64K entry, or a single, rather larger entry.
As a sanity check, I've cc'd linux-ia64.
rick jones
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists