From: Mike Travis <travis@sgi.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
rusty@rustcorp.com.au, linux-kernel@vger.kernel.org,
Jack Steiner <steiner@sgi.com>
Subject: Re: 2.6.29-rc1 does not boot
Date: Sun, 11 Jan 2009 15:19:18 -0800 [thread overview]
Message-ID: <496A7E76.2050507@sgi.com> (raw)
In-Reply-To: <496A451C.5030400@sgi.com>
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
next prev parent reply other threads:[~2009-01-11 23:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-11 14:55 2.6.29-rc1 does not boot Dieter Ries
2009-01-11 15:19 ` Ingo Molnar
2009-01-11 15:30 ` Dieter Ries
2009-01-11 15:35 ` Ingo Molnar
2009-01-11 15:41 ` Dieter Ries
2009-01-11 18:50 ` Dieter Ries
2009-01-11 19:02 ` Mike Travis
2009-01-11 19:30 ` Dieter Ries
2009-01-12 10:00 ` Ingo Molnar
2009-01-12 17:53 ` Mike Travis
2009-01-12 18:55 ` Ingo Molnar
2009-01-15 0:54 ` Rusty Russell
2009-01-11 19:02 ` Ingo Molnar
2009-01-11 19:14 ` Mike Travis
2009-01-11 23:19 ` Mike Travis [this message]
2009-01-12 1:01 ` H. Peter Anvin
2009-01-12 11:22 ` Maciej Rutecki
2009-01-12 11:26 ` Ingo Molnar
2009-01-12 11:28 ` Maciej Rutecki
2009-01-12 12:10 ` Dieter Ries
2009-01-12 12:21 ` Ingo Molnar
2009-01-12 16:37 ` Dieter Ries
2009-01-12 18:59 ` Ingo Molnar
2009-01-13 4:45 ` Michal Jaegermann
2009-01-12 17:22 ` 2.6.29-rc1 does not boot and fails to resume Rafael J. Wysocki
2009-01-14 1:16 ` 2.6.29-rc1 does not boot Rusty Russell
2009-01-14 11:30 ` Ingo Molnar
2009-01-14 12:47 ` Dieter Ries
2009-01-15 20:01 ` Mike Travis
2009-01-15 21:03 ` Dieter Ries
2009-01-15 21:48 ` Maciej Rutecki
2009-01-15 21:54 ` Mike Travis
2009-01-15 23:04 ` Maciej Rutecki
2009-01-15 23:31 ` Mike Travis
2009-01-15 21:54 ` Mike Travis
2009-01-15 23:02 ` Dieter Ries
2009-01-15 23:30 ` Mike Travis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=496A7E76.2050507@sgi.com \
--to=travis@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=steiner@sgi.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox