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
2. The PDA is used to store per cpu data before the per cpu areas
are setup.
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.
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. In loops over all per
cpu variables this will also simplify the code.
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.
-
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]
