[PATCH 00/10] NR_CPUS: third reduction of NR_CPUS memory usage x86-version v2


Wii, isn't this fun...! This is a resubmission of yesterday's patches
based on the x86.git/latest tree. Yes, it _is_ a maze of twisty litle
passages. ;-)

Patches that are actually different are marked "v2". (I did not recalculate
the memory usages changes but I did reverify the defconfig and akpm2
configs with both 255 and 4096 NR_CPUS.)
...................

Here's the third round of removing static allocations of arrays using
NR_CPUS to size the length. The change is to use PER_CPU variables in
place of the static tables, or allocate the array based on nr_cpu_ids.

In addition, there's a cleanup of x86 non-smp code, the movement of
setting nr_cpu_ids to setup_per_cpu_areas() so it's available as soon
as possible, and a new function cpumask_scnprintf_len() to return the
number of characters needed to display "len" cpumask bits.

Affected files:

arch/ia64/kernel/acpi.c
arch/ia64/kernel/setup.c
arch/powerpc/kernel/setup_64.c
arch/sparc64/mm/init.c
arch/x86/kernel/cpu/intel_cacheinfo.c
arch/x86/kernel/genapic_64.c
arch/x86/kernel/mpparse_64.c
arch/x86/kernel/setup64.c
arch/x86/kernel/smpboot_32.c
arch/x86/mm/numa_64.c
arch/x86/oprofile/nmi_int.c
drivers/acpi/processor_core.c
drivers/acpi/processor_idle.c
drivers/acpi/processor_perflib.c
drivers/acpi/processor_throttling.c
drivers/base/cpu.c
drivers/cpufreq/cpufreq.c
drivers/cpufreq/cpufreq_stats.c
drivers/cpufreq/freq_table.c
include/acpi/processor.h
include/asm-x86/smp_32.h
include/asm-x86/smp_64.h
include/asm-x86/topology.h
include/linux/bitmap.h
include/linux/cpumask.h
init/main.c
kernel/sched.c
lib/bitmap.c
net/core/dev.c

Based on:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git


Cc: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>
Cc: Andi Kleen <ak@xxxxxxx>
Cc: Anton Blanchard <anton@xxxxxxxxx>
Cc: Christoph Lameter <clameter@xxxxxxx>
Cc: Dave Jones <davej@xxxxxxxxxxxxxxxxx>
Cc: David S. Miller <davem@xxxxxxxxxxxxx>
Cc: H. Peter Anvin <hpa@xxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Cc: James Morris <jmorris@xxxxxxxxx>
Cc: Len Brown <len.brown@xxxxxxxxx>
Cc: Patrick McHardy <kaber@xxxxxxxxx>
Cc: Paul Jackson <pj@xxxxxxx>
Cc: Paul Mackerras <paulus@xxxxxxxxx>
Cc: Philippe Elie <phil.el@xxxxxxxxxx>
Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Tony Luck <tony.luck@xxxxxxxxx>
Cc: William L. Irwin <wli@xxxxxxxxxxxxxx>

Signed-off-by: Mike Travis <travis@xxxxxxx>
---

I moved the x86_64 cleanup and move-set-nr_cpu_ids from the zero-based
percpu variables patchset to this one, as I was encountering a panic
from system_call_after_swapgs() after an unknown device interrupt during
module loading. That problem will be dealt with in another patch.


Here's the various effects of the patches on memory usages using the
akpm2 config file with NR_CPUS=4096 and MAXNODES=512:

====== Data (-l 500)
1 - initial
2 - cleanup
4 - nr_cpus-in-cpufreq-cpu_alloc
5 - nr_cpus-in-acpi-driver-cpu_alloc
7 - nr_cpus-in-intel_cacheinfo
8 - nr_cpus-in-cpu_c
11 - nr_cpus-in-kernel_sched

.1. .2. .4. .5. .7. .8. .11.
32768 . -32768 . . . . show_table(.bss)
32768 . . . . . -32768 sched_group_nodes_bycpu(.bss)
32768 . . -32768 . . . processors(.bss)
32768 . . -32768 . . . processor_device_array(.bss)
32768 . . . . . -32768 init_sched_entity_p(.bss)
32768 . . . . . -32768 init_cfs_rq_p(.bss)
32768 . . .-32768 . . index_kobject(.bss)
32768 . . .-32768 . . cpuid4_info(.bss)
32768 . -32768 . . . . cpufreq_cpu_governor(.bss)
32768 . -32768 . . . . cpufreq_cpu_data(.bss)
32768 . . . . -32768 . cpu_sys_devices(.bss)
32768 . . .-32768 . . cache_kobject(.bss)

====== Text/Data ()
1 - initial
4 - nr_cpus-in-cpufreq-cpu_alloc
5 - nr_cpus-in-acpi-driver-cpu_alloc
7 - nr_cpus-in-intel_cacheinfo
8 - nr_cpus-in-cpu_c
11 - nr_cpus-in-kernel_sched

.1. .4. .5. .7. .8. .11. ..final..
3373056 . +2048 . . . 3375104 <1% TextSize
1656832 . +2048 . . . 1658880 <1% DataSize
1855488 -98304 -65536 -98304 -32768 -98304 1462272 -21% BssSize
10395648 . +4096 . . . 10399744 <1% OtherSize
17281024 -98304 -57344 -98304 -32768 -98304 16896000 -2% Totals

====== Stack (-l 500)
... files 11 vars 928 all 0 lim 500 unch 0

1 - initial
7 - nr_cpus-in-intel_cacheinfo
11 - nr_cpus-in-kernel_sched

.1. .7. .11. ..final..
4648 . -4080 568 -87% cpu_attach_domain
4104 -4104 . . -100% show_shared_cpu_map
8752 -4104 -4080 568 -93% Totals

--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Windows array allocation problem
    ... The available space has been decreasing as patches are added, ... API function GlobalMemoryStatus or GlobalMemoryStatusEx returns both the total virtual memory and available virtual memory. ... The available virtual is less than 2 GB, and I had thought that the amount used by the program, other arrays, and so forth had been subtracted, leaving the amount that's, well, available. ...
    (comp.lang.fortran)
  • Re: Q: check_unsafe_exec() races (Was: [PATCH 2/4] fix setuid sometimes doesnt)
    ... On Mon, 30 Mar 2009, Al Viro wrote: ... Shortlog of execve-related part: ... First impression is that there's lots of good cleanup in there, ... Note that Linus put the four patches I posted straight into his tree, ...
    (Linux-Kernel)
  • [PATCH 0/3] VFS fileop cleanups by collapsing AIO and vector IO
    ... Here the VFS cleanup patches to collapse vector and AIO fileop ... These series of patches clean up and streamlines generic_file_* ... After this patch set, we should end up with ONLY following ...
    (Linux-Kernel)
  • [2.6.17-mm6 PATCH 0/3] VFS fileop cleanups by collapsing AIO and vector IO
    ... Here the VFS cleanup patches to collapse vector and AIO fileop ... These series of patches clean up and streamlines generic_file_* ... After this patch set, we should end up with ONLY following ...
    (Linux-Kernel)
  • Re: [patch] checkpatch.pl: revert wrong --file message
    ... As the one who sent such a cleanup sometime ago I think I've rights to ... I think all developers would agree with me that to have a clean code is ... in my emacs settings - so every useless ... The only problem could be - such a cleanup would break patches ...
    (Linux-Kernel)