From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
Andi Kleen <ak@suse.de>
Subject: Re: [patch 05/14] percpu: Use a Kconfig variable to configure arch specific percpu setup
Date: Wed, 28 Nov 2007 17:30:38 -0800 [thread overview]
Message-ID: <474E163E.2070702@goop.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0711281604560.17738@schroedinger.engr.sgi.com>
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
next prev parent reply other threads:[~2007-11-29 1:30 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-27 0:14 [patch 00/14] Per cpu code simplification Christoph Lameter
2007-11-27 0:14 ` [patch 01/14] Modules: Handle symbols that have a zero value Christoph Lameter
2007-11-27 0:14 ` [patch 02/14] Modules: Include sections.h to avoid defining linker variables explicitly Christoph Lameter
2007-11-27 0:14 ` [patch 03/14] Modules: Fold percpu_modcopy into module.c and get rid of the macro from hell Christoph Lameter
2007-11-27 0:14 ` [patch 04/14] ia64: Remove the __SMALL_ADDR_AREA attribute for per cpu access Christoph Lameter
2007-11-27 5:20 ` David Mosberger-Tang
2007-11-27 18:15 ` Christoph Lameter
2007-11-27 21:10 ` David Mosberger-Tang
2007-11-27 21:18 ` Christoph Lameter
2007-11-27 21:27 ` David Mosberger-Tang
2007-11-27 22:02 ` Christoph Lameter
2007-11-27 9:30 ` Andreas Schwab
2007-11-27 18:17 ` Christoph Lameter
2007-11-27 21:24 ` Andreas Schwab
2007-11-27 21:38 ` Christoph Lameter
2007-11-27 22:14 ` Adrian Bunk
2007-11-27 0:14 ` [patch 05/14] percpu: Use a Kconfig variable to configure arch specific percpu setup Christoph Lameter
2007-11-27 4:30 ` Rusty Russell
2007-11-27 18:14 ` Christoph Lameter
2007-11-28 1:36 ` Rusty Russell
2007-11-28 18:51 ` Christoph Lameter
2007-11-28 23:17 ` Rusty Russell
2007-11-28 23:36 ` Christoph Lameter
2007-11-30 2:23 ` Rusty Russell
2007-11-28 23:45 ` Jeremy Fitzhardinge
2007-11-29 0:11 ` Christoph Lameter
2007-11-29 1:18 ` Andi Kleen
2007-11-29 1:27 ` Christoph Lameter
2007-11-29 1:30 ` Jeremy Fitzhardinge [this message]
2007-11-29 1:32 ` Andi Kleen
2007-11-29 1:35 ` Christoph Lameter
2007-11-29 1:42 ` Jeremy Fitzhardinge
2007-11-29 1:48 ` Christoph Lameter
2007-11-29 1:54 ` Jeremy Fitzhardinge
2007-11-29 2:06 ` Christoph Lameter
2007-11-29 5:29 ` Jeremy Fitzhardinge
2007-11-29 6:08 ` Christoph Lameter
2007-11-29 6:10 ` Christoph Lameter
2007-11-27 23:40 ` Randy Dunlap
2007-11-28 0:03 ` Christoph Lameter
2007-11-28 0:05 ` Randy Dunlap
2007-11-27 0:14 ` [patch 06/14] percpu: Move arch XX_PER_CPU_XX definitions into linux/percpu.h Christoph Lameter
2007-11-27 0:14 ` [patch 07/14] percpu: Make the asm-generic/percpu.h more generic Christoph Lameter
2007-11-27 0:14 ` [patch 08/14] x86_32: Use generic percpu.h Christoph Lameter
2007-11-27 0:14 ` [patch 09/14] x86_64: Use generic percpu Christoph Lameter
2007-11-27 0:14 ` [patch 10/14] s390: " Christoph Lameter
2007-11-27 0:14 ` [patch 11/14] Powerpc: Use generic per cpu Christoph Lameter
2007-11-27 7:41 ` Kumar Gala
2007-11-27 18:16 ` Christoph Lameter
2007-11-27 20:58 ` Paul Mackerras
2007-11-27 21:13 ` Christoph Lameter
2007-11-28 2:35 ` Paul Mackerras
2007-11-28 18:54 ` Christoph Lameter
2007-12-02 20:55 ` Benjamin Herrenschmidt
2007-11-27 0:14 ` [patch 12/14] Sparc64: Use generic percpu Christoph Lameter
2007-11-27 0:14 ` [patch 13/14] ia64: " Christoph Lameter
2007-11-27 1:37 ` Christoph Lameter
2007-11-27 0:14 ` [patch 14/14] x86: Unify percpu.h Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=474E163E.2070702@goop.org \
--to=jeremy@goop.org \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).