Eric Lee / smarc-fsl-linux-kernel

20 Jul, 2007

1 commit

  • 5fb7dc37d   define new percpu interface for shared data ... Browse Code »

    per cpu data section contains two types of data. One set which is
    exclusively accessed by the local cpu and the other set which is per cpu,
    but also shared by remote cpus. In the current kernel, these two sets are
    not clearely separated out. This can potentially cause the same data
    cacheline shared between the two sets of data, which will result in
    unnecessary bouncing of the cacheline between cpus.

    One way to fix the problem is to cacheline align the remotely accessed per
    cpu data, both at the beginning and at the end. Because of the padding at
    both ends, this will likely cause some memory wastage and also the
    interface to achieve this is not clean.

    This patch:

    Moves the remotely accessed per cpu data (which is currently marked
    as ____cacheline_aligned_in_smp) into a different section, where all the data
    elements are cacheline aligned. And as such, this differentiates the local
    only data and remotely accessed data cleanly.

    Signed-off-by: Fenghua Yu
    Acked-by: Suresh Siddha
    Cc: Rusty Russell
    Cc: Christoph Lameter
    Cc:
    Cc: "Luck, Tony"
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Fenghua Yu
     

03 May, 2007

1 commit

  • ae1ee11be   [PATCH] i386: Use per-cpu variables for GDT, PDA ... Browse Code »

    Allocating PDA and GDT at boot is a pain. Using simple per-cpu variables adds
    happiness (although we need the GDT page-aligned for Xen, which we do in a
    followup patch).

    [akpm@linux-foundation.org: build fix]
    Signed-off-by: Rusty Russell
    Signed-off-by: Andi Kleen
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton

    Rusty Russell
     

06 Oct, 2006

1 commit

26 Sep, 2006

1 commit

04 Jul, 2006

1 commit

26 Jun, 2006

1 commit

  • bfe5d8341   [PATCH] Define __raw_get_cpu_var and use it ... Browse Code »

    There are several instances of per_cpu(foo, raw_smp_processor_id()), which
    is semantically equivalent to __get_cpu_var(foo) but without the warning
    that smp_processor_id() can give if CONFIG_DEBUG_PREEMPT is enabled. For
    those architectures with optimized per-cpu implementations, namely ia64,
    powerpc, s390, sparc64 and x86_64, per_cpu() turns into more and slower
    code than __get_cpu_var(), so it would be preferable to use __get_cpu_var
    on those platforms.

    This defines a __raw_get_cpu_var(x) macro which turns into per_cpu(x,
    raw_smp_processor_id()) on architectures that use the generic per-cpu
    implementation, and turns into __get_cpu_var(x) on the architectures that
    have an optimized per-cpu implementation.

    Signed-off-by: Paul Mackerras
    Acked-by: David S. Miller
    Acked-by: Ingo Molnar
    Acked-by: Martin Schwidefsky
    Cc: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul Mackerras
     

29 Mar, 2006

1 commit

23 Mar, 2006

1 commit

  • 394e3902c   [PATCH] more for_each_cpu() conversions ... Browse Code »

    When we stop allocating percpu memory for not-possible CPUs we must not touch
    the percpu data for not-possible CPUs at all. The correct way of doing this
    is to test cpu_possible() or to use for_each_cpu().

    This patch is a kernel-wide sweep of all instances of NR_CPUS. I found very
    few instances of this bug, if any. But the patch converts lots of open-coded
    test to use the preferred helper macros.

    Cc: Mikael Starvik
    Cc: David Howells
    Acked-by: Kyle McMartin
    Cc: Anton Blanchard
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Cc: Paul Mundt
    Cc: "David S. Miller"
    Cc: William Lee Irwin III
    Cc: Andi Kleen
    Cc: Christian Zankel
    Cc: Philippe Elie
    Cc: Nathan Scott
    Cc: Jens Axboe
    Cc: Eric Dumazet
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

24 Jun, 2005

1 commit

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