Re: [RFC 00/15] x86_64: Optimize percpu accesses
From: H. Peter Anvin
Date: Wed Jul 09 2008 - 17:43:25 EST
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.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/