Re: [RFC 00/15] x86_64: Optimize percpu accesses

["H. Peter Anvin" <hpa@zytor.com>]

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