lkml.org 
[lkml]   [2007]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 05/14] percpu: Use a Kconfig variable to configure arch specific percpu setup
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-11-29 02:33    [W:0.126 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site