Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753664AbZA0Wr6 (ORCPT ); Tue, 27 Jan 2009 17:47:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752548AbZA0Wrp (ORCPT ); Tue, 27 Jan 2009 17:47:45 -0500 Received: from g1t0029.austin.hp.com ([15.216.28.36]:29064 "EHLO g1t0029.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752138AbZA0Wro (ORCPT ); Tue, 27 Jan 2009 17:47:44 -0500 Message-ID: <497F8F02.9000603@hp.com> Date: Tue, 27 Jan 2009 14:47:30 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.7.13) Gecko/20060601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Miller CC: cl@linux-foundation.org, tj@kernel.org, rusty@rustcorp.com.au, mingo@elte.hu, herbert@gondor.apana.org.au, 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, netdev@vger.kernel.org, mathieu.desnoyers@polymtl.ca, "linux-ia64@vger.kernel.org" Subject: Re: [PATCH] percpu: add optimized generic percpu accessors References: <200901271213.18605.rusty@rustcorp.com.au> <497E705B.5000302@kernel.org> <20090127.134747.153565246.davem@davemloft.net> In-Reply-To: <20090127.134747.153565246.davem@davemloft.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1265 Lines: 35 David Miller wrote: > From: Christoph Lameter > 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 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/