lkml.org 
[lkml]   [2007]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: Per-CPU data as a structure
    Andi Kleen wrote:
    >> As far as I can tell, the advantage of percpu is that you can define
    >> new "fields" anywhere in the code and independently from the rest of
    >> the system.
    >>
    >
    > - Independent maintenance as you noted
    > - Fast access and relatively compact code
    > - Avoids false sharing by keeping cache lines of different CPUs separate
    > - Doesn't waste a lot of memory in padding like NR_CPUs arrays usually
    > need to to avoid the previous point.
    >
    > Any replacement that doesn't have these properties too will probably
    > be not useful.
    >
    Thank you for the details. I'll try to stick to per-cpu wherever
    possible for now.

    Anyway, what do you think about adding the above text to the code (percpu.h
    maybe) as documentation? See the patch below. (Dunno if the Signed-off-by
    line is appropriate as most of the text is yours.)

    Signed-off-by: Julio M. Merino Vidal <jmerino@ac.upc.edu>

    diff --git a/include/linux/percpu.h b/include/linux/percpu.h
    index 600e3d3..b8e8b8c 100644
    --- a/include/linux/percpu.h
    +++ b/include/linux/percpu.h
    @@ -1,6 +1,21 @@
    #ifndef __LINUX_PERCPU_H
    #define __LINUX_PERCPU_H

    +/*
    + * percpu provides a mechanism to define variables that are specific to
    each
    + * CPU in the system.
    + *
    + * Each variable is defined as an independent array of NR_CPUS elements.
    + * This approach is used instead of a per-CPU structure because it has the
    + * following advantages:
    + * - Independent maintenance: a source file can define new per-CPU
    + * variables without distorting others.
    + * - Fast access and relatively compact code.
    + * - Avoids false sharing by keeping cache lines of different CPUs
    separate.
    + * - Doesn't waste a lot of memory in padding like NR_CPUs arrays usually
    + * need to to avoid the previous point.
    + */
    +
    #include <linux/spinlock.h> /* For preempt_disable() */
    #include <linux/slab.h> /* For kmalloc() */
    #include <linux/smp.h>

    Kind regards.
    -
    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/

    \
     
     \ /
      Last update: 2007-05-04 10:39    [W:0.022 / U:31.220 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site