Eric Lee / linux-smarc-t335x-v3.2

03 Mar, 2010

1 commit

28 Apr, 2008

1 commit

  • 1b27d05b6   mm: move cache_line_size() to <linux/cache.h> ... Browse Code »

    Not all architectures define cache_line_size() so as suggested by Andrew move
    the private implementations in mm/slab.c and mm/slob.c to .

    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: H. Peter Anvin
    Reviewed-by: Christoph Lameter
    Signed-off-by: Pekka Enberg
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pekka Enberg
     

26 Apr, 2006

1 commit

23 Mar, 2006

1 commit

  • 804f1594c   [PATCH] Move read_mostly definition to asm/cache.h ... Browse Code »

    Seems like needless clutter having a bunch of #if defined(CONFIG_$ARCH) in
    include/linux/cache.h. Move the per architecture section definition to
    asm/cache.h, and keep the if-not-defined dummy case in linux/cache.h to
    catch architectures which don't implement the section.

    Verified that symbols still go in .data.read_mostly on parisc,
    and the compile doesn't break.

    Signed-off-by: Kyle McMartin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Kyle McMartin
     

11 Jan, 2006

1 commit

09 Jan, 2006

1 commit

  • 22fc6eccb   [PATCH] Change maxaligned_in_smp alignemnt macros to internodealigned_in_smp macros ... Browse Code »

    ____cacheline_maxaligned_in_smp is currently used to align critical structures
    and avoid false sharing. It uses per-arch L1_CACHE_SHIFT_MAX and people find
    L1_CACHE_SHIFT_MAX useless.

    However, we have been using ____cacheline_maxaligned_in_smp to align
    structures on the internode cacheline size. As per Andi's suggestion,
    following patch kills ____cacheline_maxaligned_in_smp and introduces
    INTERNODE_CACHE_SHIFT, which defaults to L1_CACHE_SHIFT for all arches.
    Arches needing L3/Internode cacheline alignment can define
    INTERNODE_CACHE_SHIFT in the arch asm/cache.h. Patch replaces
    ____cacheline_maxaligned_in_smp with ____cacheline_internodealigned_in_smp

    With this patch, L1_CACHE_SHIFT_MAX can be killed

    Signed-off-by: Ravikiran Thirumalai
    Signed-off-by: Shai Fultheim
    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ravikiran G Thirumalai
     

17 Dec, 2005

1 commit

  • dc86e88c2   [IA64] Add __read_mostly support for IA64 ... Browse Code »

    sparc64, i386 and x86_64 have support for a special data section dedicated
    to rarely updated data that is frequently read. The section was created to
    avoid false sharing of those rarely read data with frequently written kernel
    data.

    This patch creates such a data section for ia64 and will group rarely written
    data into this section.

    Signed-off-by: Christoph Lameter
    Signed-off-by: Tony Luck

    Christoph Lameter
     

11 Jul, 2005

1 commit

08 Jul, 2005

1 commit

  • 6c036527a   [PATCH] mostly_read data section ... Browse Code »

    Add a new section called ".data.read_mostly" for data items that are read
    frequently and rarely written to like cpumaps etc.

    If these maps are placed in the .data section then these frequenly read
    items may end up in cachelines with data is is frequently updated. In that
    case all processors in an SMP system must needlessly reload the cachelines
    again and again containing elements of those frequently used variables.

    The ability to share these cachelines will allow each cpu in an SMP system
    to keep local copies of those shared cachelines thereby optimizing
    performance.

    Signed-off-by: Alok N Kataria
    Signed-off-by: Shobhit Dayal
    Signed-off-by: Christoph Lameter
    Signed-off-by: Shai Fultheim
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Lameter
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds