Re: [PATCH 1/3] x86-64: Convert the PDA to percpu.

From: Ingo Molnar
Date: Sat Dec 27 2008 - 10:54:19 EST



* Brian Gerst <brgerst@xxxxxxxxx> wrote:

> On Sat, Dec 27, 2008 at 5:41 AM, Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> > (Cc:-ed a few more people who might be interested in this)
> >
> > * Brian Gerst <brgerst@xxxxxxxxx> wrote:
> >
> >> This patch makes the PDA a normal per-cpu variable, allowing the
> >> removal of the special allocator code. %gs still points to the
> >> base of the PDA.
> >>
> >> Tested on a dual-core AMD64 system.
> >>
> >> Signed-off-by: Brian Gerst <brgerst@xxxxxxxxx>
> >> ---
> >> arch/x86/include/asm/pda.h | 3 --
> >> arch/x86/include/asm/percpu.h | 3 --
> >> arch/x86/include/asm/setup.h | 1 -
> >> arch/x86/kernel/cpu/common.c | 6 ++--
> >> arch/x86/kernel/dumpstack_64.c | 8 ++--
> >> arch/x86/kernel/head64.c | 23 +------------
> >> arch/x86/kernel/irq.c | 2 +-
> >> arch/x86/kernel/nmi.c | 2 +-
> >> arch/x86/kernel/setup_percpu.c | 70 ++++++++--------------------------------
> >> arch/x86/kernel/smpboot.c | 58 +--------------------------------
> >> arch/x86/xen/enlighten.c | 2 +-
> >> arch/x86/xen/smp.c | 12 +------
> >> 12 files changed, 27 insertions(+), 163 deletions(-)
> >
> > the simplification factor is significant. I'm wondering, have you measured
> > the code size impact of this on say the defconfig x86 kernel? That will
> > generally tell us how much worse optimizations the compiler does under
> > this scheme.
> >
> > Ingo
> >
>
> Patch #1 by itself doesn't change how the PDA is accessed, only how it
> is allocated. The text size goes down significantly with patch #1,
> but data goes up. Changing the PDA to cacheline-aligned (1a) brings
> it back in line.
>
> text data bss dec hex filename
> 7033648 1754476 758508 9546632 91ab88 vmlinux.0 (vanilla 2.6.28)
> 7029563 1758428 758508 9546499 91ab03 vmlinux.1 (with patch #1)
> 7029563 1754460 758508 9542531 919b83 vmlinux.1a (with patch #1 cache align)
> 7036694 1758428 758508 9553630 91c6de vmlinux.3 (with all three patches)
>
> I think the first patch (with the alignment fix) is a clear win. As for
> the other patches, they add about 8 bytes per use of a PDA variable.
> cpu_number is used 903 times in this compile, so this is likely the most
> extreme example. I have an idea to optimize this particular case
> further that I'd like to look at which would lessen the impact.

curious, what idea is that?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/