Eric Lee / smarc-fsl-linux-kernel

20 Oct, 2007

1 commit

  • 92cb7612a   x86: convert cpuinfo_x86 array to a per_cpu array ... Browse Code »

    cpu_data is currently an array defined using NR_CPUS. This means that
    we overallocate since we will rarely really use maximum configured cpus.
    When NR_CPU count is raised to 4096 the size of cpu_data becomes
    3,145,728 bytes.

    These changes were adopted from the sparc64 (and ia64) code. An
    additional field was added to cpuinfo_x86 to be a non-ambiguous cpu
    index. This corresponds to the index into a cpumask_t as well as the
    per_cpu index. It's used in various places like show_cpuinfo().

    cpu_data is defined to be the boot_cpu_data structure for the NON-SMP
    case.

    Signed-off-by: Mike Travis
    Acked-by: Christoph Lameter
    Cc: Andi Kleen
    Cc: James Bottomley
    Cc: Dmitry Torokhov
    Cc: "Antonino A. Daplas"
    Cc: Mark M. Hoffman
    Signed-off-by: Andrew Morton
    Signed-off-by: Ingo Molnar
    Signed-off-by: Thomas Gleixner

    Mike Travis
     

17 Oct, 2007

2 commits

  • d5a7430dd   Convert cpu_sibling_map to be a per cpu variable ... Browse Code »

    Convert cpu_sibling_map from a static array sized by NR_CPUS to a per_cpu
    variable. This saves sizeof(cpumask_t) * NR unused cpus. Access is mostly
    from startup and CPU HOTPLUG functions.

    Signed-off-by: Mike Travis
    Cc: Andi Kleen
    Cc: Christoph Lameter
    Cc: "Siddha, Suresh B"
    Cc: "David S. Miller"
    Cc: Paul Mackerras
    Cc: Benjamin Herrenschmidt
    Cc: "Luck, Tony"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Travis
     
  • 083576112   x86: Convert cpu_core_map to be a per cpu variable ... Browse Code »

    This is from an earlier message from 'Christoph Lameter':

    cpu_core_map is currently an array defined using NR_CPUS. This means that
    we overallocate since we will rarely really use maximum configured cpu.

    If we put the cpu_core_map into the per cpu area then it will be allocated
    for each processor as it comes online.

    This means that the core map cannot be accessed until the per cpu area
    has been allocated. Xen does a weird thing here looping over all processors
    and zeroing the masks that are not yet allocated and that will be zeroed
    when they are allocated. I commented the code out.

    Signed-off-by: Christoph Lameter
    Signed-off-by: Mike Travis
    Cc: Andi Kleen
    Cc: Christoph Lameter
    Cc: "Siddha, Suresh B"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Travis
     

11 Oct, 2007

1 commit