| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 11 Jan 2009 15:19:18 -0800
From: Mike Travis <travis@....com>
To: Ingo Molnar <mingo@...e.hu>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, rusty@...tcorp.com.au,
linux-kernel@...r.kernel.org, Jack Steiner <steiner@....com>
Subject: Re: 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists