From: Mike Travis <travis@sgi.com>
To: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Roland Dreier <rdreier@cisco.com>,
Randy Dunlap <rdunlap@xenotime.net>, Tejun Heo <tj@kernel.org>,
Andi Kleen <andi@firstfloor.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
"H. Peter Anvin" <hpa@zytor.com>,
David Rientjes <rientjes@google.com>,
Steven Rostedt <rostedt@goodmis.org>,
Rusty Russell <rusty@rustcorp.com.au>,
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>,
Jack Steiner <steiner@sgi.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] x86: Limit the number of processor bootup messages
Date: Wed, 18 Nov 2009 09:43:41 -0800 [thread overview]
Message-ID: <4B04324D.6050508@sgi.com> (raw)
In-Reply-To: <86802c440911171845v1dae0f27i78ee7347d0f315d0@mail.gmail.com>
Yinghai Lu wrote:
> On Tue, Nov 17, 2009 at 4:22 PM, Mike Travis <travis@sgi.com> wrote:
>> When there are a large number of processors in a system, there
>> is an excessive amount of messages sent to the system console.
>> It's estimated that with 4096 processors in a system, and the
>> console baudrate set to 56K, the startup messages will take
>> about 84 minutes to clear the serial port.
>>
>> This set of patches limits the number of repetitious messages
>> which contain no additional information. Much of this information
>> is obtainable from the /proc and /sysfs. Some of the messages
>> are also sent to the kernel log buffer as KERN_DEBUG messages so
>> dmesg can be used to examine more closely any details specific to
>> a problem.
>>
>> The new cpu bootup sequence for system_state == SYSTEM_BOOTING:
>>
>> Booting Node 0, Processors #1 #2 #3 #4 #5 #6 #7 Ok.
>> Booting Node 1, Processors #8 #9 #10 #11 #12 #13 #14 #15 Ok.
>> ..
>> Booting Node 3, Processors #56 #57 #58 #59 #60 #61 #62 #63 Ok.
>> Brought up 64 CPUs
>
> how about
> Booting Node 0, Processors #1/0x01 #2/0x02 #3....
> append apic id in hex after the numbering.?
>
> YH
The APIC id's are already listed earlier in the log. There are
some other APIC patches to deal with making the output clearer
as well as more/less verbose.
next prev parent reply other threads:[~2009-11-18 17:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-18 0:22 [PATCH 0/5] Limit console output by suppressing repetitious messages Mike Travis
2009-11-18 0:22 ` [PATCH 1/5] x86: Limit the number of processor bootup messages Mike Travis
2009-11-18 2:45 ` Yinghai Lu
2009-11-18 17:43 ` Mike Travis [this message]
2009-11-26 9:15 ` Ingo Molnar
2009-11-27 21:29 ` [PATCH] " Mike Travis
2009-11-18 0:22 ` [PATCH 2/5] INIT: Limit the number of per cpu calibration " Mike Travis
2009-11-26 9:55 ` [tip:timers/core] timers, init: " tip-bot for Mike Travis
2009-11-18 0:22 ` [PATCH 3/5] firmware: Limit the number of per cpu firmware messages during bootup Mike Travis
2009-11-18 0:22 ` [PATCH 4/5] sched: Limit the number of scheduler debug messages Mike Travis
2009-11-26 9:55 ` [tip:sched/core] " tip-bot for Mike Travis
2009-11-18 0:22 ` [PATCH 5/5] x86: Limit number of per cpu TSC sync messages Mike Travis
2009-11-26 9:55 ` [tip:x86/debug] " tip-bot for Mike Travis
-- strict thread matches above, loose matches on Subject: below --
2009-11-17 19:17 [PATCH 0/5] Limit console output by suppressing repetitious messages Mike Travis
2009-11-17 19:17 ` [PATCH 1/5] x86: Limit the number of processor bootup messages Mike Travis
2009-11-17 20:10 ` Yinghai Lu
2009-11-17 20:29 ` H. Peter Anvin
2009-11-17 21:11 ` Yinghai Lu
2009-11-18 2:38 ` Yinghai Lu
2009-11-18 17:44 ` Mike Travis
2009-11-18 17:43 ` Mike Travis
2009-11-17 21:05 ` Mike Travis
2009-11-18 10:48 ` Borislav Petkov
2009-11-18 17:18 ` Mike Travis
2009-11-18 18:08 ` Borislav Petkov
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=4B04324D.6050508@sgi.com \
--to=travis@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=fweisbec@gmail.com \
--cc=gregkh@suse.de \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rdreier@cisco.com \
--cc=rdunlap@xenotime.net \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=steiner@sgi.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=x86@kernel.org \
--cc=yhlu.kernel@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.