Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759208AbYFQOVU (ORCPT ); Tue, 17 Jun 2008 10:21:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757709AbYFQOVL (ORCPT ); Tue, 17 Jun 2008 10:21:11 -0400 Received: from relay1.sgi.com ([192.48.171.29]:55332 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757386AbYFQOVK (ORCPT ); Tue, 17 Jun 2008 10:21:10 -0400 Message-ID: <4857C850.103@sgi.com> Date: Tue, 17 Jun 2008 07:21:04 -0700 From: Mike Travis User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: Rusty Russell CC: Christoph Lameter , Nick Piggin , Martin Peschke , Andrew Morton , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, David Miller , Eric Dumazet , Peter Zijlstra Subject: Re: [patch 04/41] cpu ops: Core piece for generic atomic per cpu operations References: <20080530035620.587204923@sgi.com> <200806152033.02891.rusty@rustcorp.com.au> <200806171024.40662.rusty@rustcorp.com.au> In-Reply-To: <200806171024.40662.rusty@rustcorp.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1462 Lines: 33 Rusty Russell wrote: > On Tuesday 17 June 2008 00:52:08 Christoph Lameter wrote: >> On Sun, 15 Jun 2008, Rusty Russell wrote: >>>> 3. Some hooks for arches to override particular behavior as needed. >>>> F.e. IA64 allocates percpu structures in a special way. x86_64 >>>> needs to do some tricks for the pda etc etc. >>> IA64 is going to need some work, since dynamic percpu addresses won't be >>> able to use their pinned TLB trick to get the local version. >> The ia64 hook could simply return the address of percpu area that >> was reserved when the per node memory layout was generated (which happens >> very early during node bootstrap). > > Apologies, this time I read the code. I thought IA64 used the pinned TLB area > to access per-cpu vars under some circumstances, but they only do that via an > arch-specific macro. > > So creating new congruent mappings to expand the percpu area(s) is our main > concern now? > > Rusty. Not exactly. Getting the system to not panic early in the boot (before x86_64_start_kernel()) is the primary problem right now. This happens in the tip tree with the change to use zero-based percpu offsets. It gets much farther on the linux-next tree. Thanks, Mike -- 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/