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/