[lkml]   [2008]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 00/15] x86_64: Optimize percpu accesses
Christoph Lameter wrote:
> Jeremy Fitzhardinge wrote:
>> No, it makes no difference. %gs:X always has a 32-bit offset in the
>> instruction, regardless of how big X is:
>> mov %eax, %gs:0
>> mov %eax, %gs:0x1234567
>> ->
>> 0: 65 89 04 25 00 00 00 00 mov %eax,%gs:0x0
>> 8: 65 89 04 25 67 45 23 01 mov %eax,%gs:0x1234567
> The processor itself supports smaller offsets.

No, it doesn't, unless you have a base register. There is no naked
disp8 form, and disp16 is only available in 16- or 32-bit mode (and in
32-bit form it requires a 67h prefix.)

> Note also that the 32 bit offset size limits the offset that can be added to the segment register. You either need to place the per cpu area either in the last 2G of the address space or in the first 2G. The zero based approach removes that limitation.

The offset is either ±2 GB from the segment register, or ±2 GB from the
segment register plus %rip. The latter is more efficient.

The processor *does* permit a 64-bit absolute form, which can be used
with a segment register, but that one is hideously restricted (only move
to/from %rax) and bloated (10 bytes!)

>> 0: 65 89 05 00 00 00 00 mov %eax,%gs:0(%rip) # 0x7
> RIP relative also implies a 32 bit offset meaning that the code cannot be more than 2G away from the per cpu area.

Not from the per cpu area, but from the linked address of the per cpu
area (the segment register base can point anywhere.)

In our case means between -2 GB and a smallish positive value (I believe
it is guaranteed to be 2 MB or more.)

Being able to use %rip-relative forms would save a byte per reference,
which is valuable.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2008-07-09 23:45    [W:0.180 / U:19.736 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site