lkml.org 
[lkml]   [2009]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.29-rc1 does not boot
Mike Travis wrote:
> Ingo Molnar wrote:
...
>> Mike, most of the work_on_cpu() patches you did so far were rather
>> problematic. Especially something like cpufreq can run rather early during
>> bootup or during suspend/resume, so i'm not sure it's correct to rely on
>> keventd for it.
>>
>> I dont see anything particularly wrong in the commit itself - but
>> obviously it causes this boot hang - if the bug is not found we'll revert
>> it .
>
> All of these are low use functions, primarily used when bringing up
> cpus. So reverting the patches does not have a big effect on the stack
> size problem.

Btw, we're looking great with stack space. This is using the 'allyesconfig'
config with NR_CPUS=4096, MAX_NUMNODES=512, and 128-allyesconfig having
NR_CPUS=128, MAX_NUMNODES=64.

====== Stack (-l 500)
1 - 128-allyesconfig
2 - allyesconfig

.1. .2. .delta.
0 600 600 . shmem_getpage
0 600 600 . powernowk8_target
0 584 584 . powernowk8_cpu_init
0 584 584 . __percpu_alloc_mask
0 552 552 . smp_call_function_many
0 536 536 . reload_store
0 528 528 . get_cur_freq
0 528 528 . check_supported_cpu
0 520 520 . powernowk8_get
0 520 520 . microcode_write
0 520 520 . microcode_init_cpu

In Data space we've still got a couple of memory hogs:

====== Data (-l 500)
1 - 128-allyesconfig
2 - allyesconfig

.1. .2. .delta.
16384 524288 +507904 +3100% boot_pageset(.bss) [1]
23816 483080 +459264 +1928% kmalloc_caches(.data.cacheline_aligned) [2]
17408 132096 +114688 +658% irq_info(.bss) [3]
17408 132096 +114688 +658% irq_bindcount(.bss) [3]
1020 131072 +130052 +12750% apic_version(.bss) [4]
3072 98304 +95232 +3100% ucode_cpu_info(.bss) [5]
2048 65536 +63488 +3100% kgdb_info(.bss) [5]
5120 40960 +35840 +700% node_devices(.bss) [6]
5216 36952 +31736 +608% iter(.bss) [???]
6404 33284 +26880 +419% e820_saved(.bss) [7]
6404 33284 +26880 +419% e820(.bss) [7]
1040 33280 +32240 +3100% cpu_bit_bitmap(.rodata) [8]
1064 32808 +31744 +2983% max_tr(.bss) [9]
1064 32808 +31744 +2983% global_trace(.bss) [9]
1024 32768 +31744 +3100% fcoe_percpu(.bss) [10]

[1]: very hard to fix, might be able to use early per_cpu_alloc when available
[2]: can be fixed when early per_cpu_alloc available
[3]: sized by NR_IRQS which can be fixed now
[4]: currently apic_version[MAX_APICS] which is a very sparsely filled array
[5]: sized by NR_CPUS, can be dynamically allocated
[6]: sized by MAX_NUMNODES, also can be dynamically allocated
[7]: sized by MAX_NUMNODES, not so easily modified
[8]: will fix when cpumask_size() is sized by nr_cpu_ids instead of NR_CPUS
[9]: struct trace_array has an NR_CPUS array component
[10]: pointer list sized by NR_CPUS


Overall, the percentages are good:

====== Text/Data ()
1 - 128-allyesconfig
2 - allyesconfig

.1. .2. .delta.
33490944 33499136 +8192 +0.02% TextSize
45527040 45598720 +71680 +0.16% DataSize
11315200 12685312 +1370112 +12% BssSize
3436544 4231168 +794624 +23% InitSize [1]
1904640 1910784 +6144 +0.32% PerCPU
333824 794624 +460800 +138% OtherSize

[1]: remember, this space is "given back" after system initializes.

Here the section detail:

====== Sections (-l 500)
1 - 128-allyesconfig
2 - allyesconfig

.1. .2. .delta.
11316152 12685496 +1369344 +12% .bss
32384 491648 +459264 +1418% .data.cacheline_aligned
370195151 370555424 +360273 +0.10% .debug_info
7358485 7445195 +86710 +1.18% .debug_abbrev
23003987 23045427 +41440 +0.18% .rodata
21248744 21281904 +33160 +0.16% .data
43877348 43890141 +12793 +0.03% .debug_loc
66728 76984 +10256 +15% .data.read_mostly
33491529 33498553 +7024 +0.02% .text
26088048 26094032 +5984 +0.02% .debug_ranges
1904288 1910176 +5888 +0.31% .data.percpu
19530974 19532151 +1177 +0.01% .debug_line
153072 152432 -640 -0.42% __param
836911 837706 +795 +0.09% .init.text


\
 
 \ /
  Last update: 2009-01-12 00:21    [from the cache]
©2003-2011 Jasper Spaans