[PATCH 0/4] percpu: Optimize percpu accesses - Kernel

This is a discussion on [PATCH 0/4] percpu: Optimize percpu accesses - Kernel ; This patchset provides the following: * Generic: Percpu infrastructure to rebase the per cpu area to zero This provides for the capability of accessing the percpu variables using a local register instead of having to go through a table on ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: [PATCH 0/4] percpu: Optimize percpu accesses

  1. [PATCH 0/4] percpu: Optimize percpu accesses


    This patchset provides the following:

    * Generic: Percpu infrastructure to rebase the per cpu area to zero

    This provides for the capability of accessing the percpu variables
    using a local register instead of having to go through a table
    on node 0 to find this cpu specific offsets. It also would allow
    atomic operations on percpu variables to reduce required locking.

    * Init: Move setup of nr_cpu_ids to as early as possible for usage
    by early boot functions.

    * x86_64: Fold pda into per cpu area

    Declare the pda as a per cpu variable. This will move the pda
    area to an address accessible by the x86_64 per cpu macros.
    Subtraction of __per_cpu_start will make the offset based from
    the beginning of the per cpu area. Since %gs is pointing to the
    pda, it will then also point to the per cpu variables and can be
    accessed thusly:

    %gs:[&per_cpu_xxxx - __per_cpu_start]

    * x86_64: Rebase per cpu variables to zero

    Take advantage of the zero-based per cpu area provided above.
    Then we can directly use the x86_32 percpu operations. x86_32
    offsets %fs by __per_cpu_start. x86_64 has %gs pointing directly
    to the pda and the per cpu area thereby allowing access to the
    pda with the x86_64 pda operations and access to the per cpu
    variables using x86_32 percpu operations. After rebasing
    the access now becomes:

    %gs:[&per_cpu_xxxx]

    Introduces a new DEFINE_PER_CPU_FIRST to locate the percpu
    variable (pda in this case) at the beginning of the percpu
    .data section.

    * x86_64: Cleanup non-smp usage of cpu maps

    Cleanup references to the early cpu maps for the non-SMP configuration
    and remove some functions called for SMP configurations only.

    Based on linux-2.6.git + x86.git

    Signed-off-by: Christoph Lameter
    Signed-off-by: Mike Travis
    ---
    Notes:

    (1 - had to disable CONFIG_SIS190 to build)
    (2 - no modules)

    Configs built and booted:

    x86_64-default
    x86_64-defconfig (2)
    x86_64-nonuma (2)
    x86_64-nosmp (2)
    x86_64-"Ingo Stress Test" (1,2)

    Configs built with no errors:

    arm-default
    i386-allyesconfig (1)
    i386-allmodconfig (1)
    i386-defconfig
    i386-nosmp
    ppc-pmac32
    ppc-smp
    sparc64-default
    sparc64-smp
    x86_64-allmodconfig (1)
    x86_64-allyesconfig (1)
    x86_64-maxsmp (NR_CPUS=4k, MAXNODES=512)

    Configs with errors prior to patch (preventing full build checkout):

    ia64-sn2: undefined reference to `mem_map' (more)
    ia64-default: (same error)
    ia64-nosmp: `per_cpu__kstat' truncated in .bss (more)
    s390-default: implicit declaration of '__raw_spin_is_contended'
    sparc-default: include/asm/pgtable.h: syntax '___f___swp_entry'

    Memory Effects (using x86_64-maxsmp config):

    Note that 1/2MB has been moved from permanent data to
    the init data section, (which is removed after bootup),
    while the per cpu section is only increased by 128 bytes
    per cpu. Also text size is reduced increasing cache
    performance.

    4k-cpus-before 4k-cpus-after
    6588928 .data.cacheline_alig -524288 -7%
    48072 .data.percpu +128 +0%
    4804576 .data.read_mostly -32656 +0%
    854048 .init.data +557056 +65%
    160382 .init.text +62 +0%
    1254214 .rodata +274 +0%
    3915552 .text -1632 +0%
    11040 __param -272 -2%

    3915552 Text -1632 +0%
    1085440 InitData +557056 +51%
    11454056 OtherData -557056 -4%
    48072 PerCpu +128 +0%
    20459748 Total -1330 +0%

    --
    --
    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/

  2. Re: [PATCH 3/4] x86_64: Fold pda into per cpu area


    * travis@sgi.com wrote:

    > include/asm-generic/vmlinux.lds.h | 2 +
    > include/linux/percpu.h | 9 ++++-


    couldnt these two generic bits be done separately (perhaps a preparatory
    but otherwise NOP patch pushed upstream straight away) to make
    subsequent patches only touch x86 architecture files?

    Ingo
    --
    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/

  3. Re: [PATCH 4/4] x86_64: Cleanup non-smp usage of cpu maps


    * travis@sgi.com wrote:

    > Cleanup references to the early cpu maps for the non-SMP configuration
    > and remove some functions called for SMP configurations only.


    thanks, applied.

    Ingo
    --
    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/

  4. Re: [PATCH 3/4] x86_64: Fold pda into per cpu area

    On Fri, 15 Feb 2008, Ingo Molnar wrote:

    >
    > * travis@sgi.com wrote:
    >
    > > include/asm-generic/vmlinux.lds.h | 2 +
    > > include/linux/percpu.h | 9 ++++-

    >
    > couldnt these two generic bits be done separately (perhaps a preparatory
    > but otherwise NOP patch pushed upstream straight away) to make
    > subsequent patches only touch x86 architecture files?


    Yes those modifications could be folded into the generic patch for zero
    based percpu configurations.
    --
    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/

  5. Re: [PATCH 3/4] x86_64: Fold pda into per cpu area

    On Feb 15, 2008 12:16 PM, Ingo Molnar wrote:
    >
    > * travis@sgi.com wrote:
    >
    > > include/asm-generic/vmlinux.lds.h | 2 +
    > > include/linux/percpu.h | 9 ++++-

    >
    > couldnt these two generic bits be done separately (perhaps a preparatory
    > but otherwise NOP patch pushed upstream straight away) to make
    > subsequent patches only touch x86 architecture files?


    this patch need to apply to mainline asap.

    or you need revert to the patch about include/asm-x86/percpu.h

    +#ifdef CONFIG_X86_64
    +#include
    +
    +/* Same as asm-generic/percpu.h, except that we store the per cpu offset
    + in the PDA. Longer term the PDA and every per cpu variable
    + should be just put into a single section and referenced directly
    + from %gs */
    +
    +#ifdef CONFIG_SMP
    +#include
    +
    +#define __per_cpu_offset(cpu) (cpu_pda(cpu)->data_offset)
    +#define __my_cpu_offset read_pda(data_offset)
    +
    +#define per_cpu_offset(x) (__per_cpu_offset(x))
    +
    #endif
    +#include
    +
    +DECLARE_PER_CPU(struct x8664_pda, pda);
    +
    +#else /* CONFIG_X86_64 */

    because current tree
    in setup_per_cpu_areas will have
    cpu_pda(i)->data_offset = ptr - __per_cpu_start;

    but at that time all APs will use cpu_pda for boot cpu...,and APs will
    get their pda in do_boot_cpu()

    the result is all cpu will have same data_offset, there will share one
    per_cpu_data..that is totally wrong!!

    that could explain a lot of strange panic ....recently about NUMA...

    YH
    --
    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/

  6. Re: [PATCH 3/4] x86_64: Fold pda into per cpu area

    On Feb 16, 2008 10:22 PM, Yinghai Lu wrote:
    > On Feb 15, 2008 12:16 PM, Ingo Molnar wrote:
    > >
    > > * travis@sgi.com wrote:
    > >
    > > > include/asm-generic/vmlinux.lds.h | 2 +
    > > > include/linux/percpu.h | 9 ++++-

    > >
    > > couldnt these two generic bits be done separately (perhaps a preparatory
    > > but otherwise NOP patch pushed upstream straight away) to make
    > > subsequent patches only touch x86 architecture files?

    >
    > this patch need to apply to mainline asap.
    >
    > or you need revert to the patch about include/asm-x86/percpu.h
    >
    > +#ifdef CONFIG_X86_64
    > +#include
    > +
    > +/* Same as asm-generic/percpu.h, except that we store the per cpu offset
    > + in the PDA. Longer term the PDA and every per cpu variable
    > + should be just put into a single section and referenced directly
    > + from %gs */
    > +
    > +#ifdef CONFIG_SMP
    > +#include
    > +
    > +#define __per_cpu_offset(cpu) (cpu_pda(cpu)->data_offset)
    > +#define __my_cpu_offset read_pda(data_offset)
    > +
    > +#define per_cpu_offset(x) (__per_cpu_offset(x))
    > +
    > #endif
    > +#include
    > +
    > +DECLARE_PER_CPU(struct x8664_pda, pda);
    > +
    > +#else /* CONFIG_X86_64 */
    >
    > because current tree
    > in setup_per_cpu_areas will have
    > cpu_pda(i)->data_offset = ptr - __per_cpu_start;
    >
    > but at that time all APs will use cpu_pda for boot cpu...,and APs will
    > get their pda in do_boot_cpu()


    sorry, boot_cpu_pda is array... so that is safe.

    YH
    --
    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/

+ Reply to Thread