lkml.org 
[lkml]   [2008]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 00/15] x86_64: Optimize percpu accesses
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


\
 
 \ /
  Last update: 2008-07-10 16:41    [W:0.135 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site