Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758570AbYGJOeP (ORCPT ); Thu, 10 Jul 2008 10:34:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758274AbYGJOdp (ORCPT ); Thu, 10 Jul 2008 10:33:45 -0400 Received: from terminus.zytor.com ([198.137.202.10]:57755 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758269AbYGJOdo (ORCPT ); Thu, 10 Jul 2008 10:33:44 -0400 Message-ID: <48761C06.3020003@zytor.com> Date: Thu, 10 Jul 2008 10:26:14 -0400 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Christoph Lameter CC: Jeremy Fitzhardinge , "Eric W. Biederman" , Ingo Molnar , Mike Travis , Andrew Morton , Jack Steiner , linux-kernel@vger.kernel.org, Arjan van de Ven Subject: Re: [RFC 00/15] x86_64: Optimize percpu accesses References: <20080709165129.292635000@polaris-admin.engr.sgi.com> <20080709200757.GD14009@elte.hu> <48751B57.8030605@goop.org> <48751CF9.4020901@linux-foundation.org> <4875209D.8010603@goop.org> <48752CCD.30507@linux-foundation.org> <48753C99.5050408@goop.org> <487555A8.2050007@zytor.com> <487556A5.5090907@goop.org> <4876194E.4080205@linux-foundation.org> In-Reply-To: <4876194E.4080205@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1; 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: 2042 Lines: 40 Christoph Lameter wrote: > With the zero based approach you do not have a relative address anymore. We are basically creating a new absolute address space where we place variables starting at zero. > > This means that we are fully independent from the placement of the percpu segment. > > The loader may place the per cpu segment with the initialized variables anywhere. We just need to set GS correctly for the boot cpu. We always need to refer to the per cpu variables > via GS or by adding the per cpu offset to the __per_cpu_offset[] (which is now badly named because it points directly to the start of the percpu segment for each processor). > > So there is no 2G limitation on the distance between the code and the percpu segment anymore. The 2G limitation still exists for the *size* of the per cpu segment. If we go beyond 2G in defined per cpu variables then the per cpu addresses will wrap. Okay, this is getting somewhat annoying. Several people now have missed the point. Noone has talked about the actual placement of the percpu segment data. Using RIP-based references, however, are *cheaper* than using absolute references. For RIP-based references to be valid, then the *offsets* need to be in the range [-2 GB + CONFIG_PHYSICAL_START ... CONFIG_PHYSICAL_START). This is similar to the constraint on absolute refereces, where the *offsets* have to be in the range [-2 GB, 2 GB). None of this affects the absolute positioning of the data. The final address are determined by: fs_base + rip + offset or fs_base + offset ... respectively. fs_base is an arbitrary 64-bit number; rip (in the kernel) is in the range [-2 GB + CONFIG_PHYSICAL_START, 0), and offset is in the range [-2 GB, 2 GB). (The high end of the rip range above is slightly too wide.) -hpa -- 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/