Christoph Lameter wrote:
> On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
>
> > Yes, I would like to convert x86_64 to match i386's percpu, and drop the
>
>> pda altogether. The only thing preventing this is the stack canary, and
>> I'm wondering how much value there is in keeping it, given the
>> disadvantages of having this divergence between 32 and 64 bit.
>>
>
> I think most of the PDA could be gotten rid of. The problems are
>
> 1. The stack canary
>
Yes, this is a biggie. It needs one of:
* fix gcc
* post-process the .s file
* drop support for stack-protector (does it really help? do people
use it?)
> 2. The PDA is used to store per cpu data before the per cpu areas
> are setup.
>
I don't see the problem. The way i386 does it inherently supports
per-cpu data very early on (it uses the prototype percpu section until
the real percpu values are set up).
> The i386 way of referring to per cpu data is not optimal because it is
> always offset by __per_cpu_start. per cpu data offsets need to be relative
> to the beginning of the per cpu area. per cpu data is less than 64k so 2
> byte offsets would be enough.
>
I don't see that's terribly important. percpu references aren't all
that common overall, and - at least on x86 - using a 16-bit offset
(assuming its possible) would require a prefix anyway, so it would only
save 1 byte per reference. But I can't convince gas to generate a
16-bit offset anyway.
> That way the __per_cpu_offset array and the registers that are used on
> various platforms are pointing to the actual data and can be loaded
> directly into a register and then a load with a small offset to that
> register can be performed. On x86_64 this is gs, on i386 fs, on sparc g5,
> on ia64 a fixed address stands in for the register.
The asm used to generate these references is inherently arch-specific
anyway, so the type and size of offset needed from the per-cpu base
register to the data itself can be arch-dependent without loss of
generality.
I definitely see that small offsets might be useful for other
architectures, but for x86 it doesn't help and makes things more
complex. The only difference between 32- and 64-bit is whether we
generate an offset from %fs, %gs or nothing (for the UP case).
> In loops over all per
> cpu variables this will also simplify the code.
>
Why's that?
> And ultimately we can get rid of the ugly RELOC_HIDE macro. It simply
> becomes the adding of the base address in a register to a per cpu offset.
>
I was never quite sure what that was for.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
