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

[Ingo Molnar <mingo@elte.hu>]

* Brian Gerst <brgerst@gmail.com> wrote:

> On Sat, Dec 27, 2008 at 5:41 AM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > (Cc:-ed a few more people who might be interested in this)
> >
> > * Brian Gerst <brgerst@gmail.com> 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@gmail.com>
> >> ---
> >>  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