lkml.org 
[lkml]   [2008]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/3] x86-64: Convert the PDA to percpu.

    * 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


    \
     
     \ /
      Last update: 2008-12-27 16:57    [W:0.044 / U:169.700 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site