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/7] x86: Limit the number of processor bootup messages
Date: Fri, 13 Nov 2009 05:46:13 -0800 [thread overview]
Message-ID: <4AFD6325.8000000@sgi.com> (raw)
In-Reply-To: <86802c440911121410v30c5b00ewdd9ada71096b4e65@mail.gmail.com>
Yinghai Lu wrote:
> On Thu, Nov 12, 2009 at 9:19 AM, Mike Travis <travis@sgi.com> wrote:
>> With 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. Most of the messages are also sent to the kernel log
>> buffer as KERN_DEBUG messages so it can be used to examine more closely any
>> details specific to a processor.
>>
>> The list of message transformations....
>>
>> For system_state == SYSTEM_BOOTING:
>>
>> [ 18.669304] Booting Node 0, Processors 1 2 3 4 5 6 7 Ok.
>> [ 19.321065] Booting Node 1, Processors 8 9 10 11 12 13 14 15 Ok.
>> [ 20.065325] Booting Node 2, Processors 16 17 18 19 20 21 22 23 Ok.
>> ..
>> [ 117.153053] Booting Node 63, Processors 1016 1017 1018 1019 1020 1021 1022 1023 Ok.
>> [ 117.952235] Brought up 1024 CPUs
>>
>> Timing shows that with NO bootup messages, it takes only slightly less time
>> so printing adds very little overhead:
>>
>> [ 18.670219] Booting all processors
>> [ 117.180248] Brought up 1024 CPUs
>>
>> For Processor Information printout, the specifics of CPU0 are printed and
>> then at the end of the bootup sequence, a summary is printed:
>>
>> [ 117.957682] Processor Information for CPUS: 0-191,208-223,256-271,...
>> [ 117.968034] Genuine Intel(R) CPU 0000 @ 2.13GHz stepping 04
>> [ 117.977406] BogoMIPS: MIN 3989.01 (7978031) AVG 4266.62 (8533249) MAX 4537.51 (9075028)
>> [ 117.984496] Processor Information for CPUS: 192-207,240-255,272-287,...
>> [ 117.996032] Genuine Intel(R) CPU 0000 @ 2.13GHz stepping 03
>> [ 118.001404] BogoMIPS: MIN 4021.49 (8042995) AVG 4265.91 (8531833) MAX 4479.79 (8959584)
>> [ 118.012373] Processor Information for CPUS: 224-239,736-751
>> [ 118.020032] Genuine Intel(R) CPU 0000 @ 1.87GHz stepping 03
>> [ 118.028033] BogoMIPS: MIN 3733.92 (7467855) AVG 3746.96 (7493933) MAX 3939.52 (7879056)
>> [ 118.036360] Processor Information for CPUS: 320-335,384-415,432-447,...
>> [ 118.044032] Intel(R) Xeon(R) CPU X7560 @ 2.27GHz stepping 05
>> [ 118.053404] BogoMIPS: MIN 4244.65 (8489318) AVG 4532.45 (9064917) MAX 4666.80 (9333604)
>> [ 118.060644] Total of 1024 processors activated (4386353.46 BogoMIPS).
>>
>>
>> The following lines have been removed:
>>
>> CPU: Physical Processor ID:
>> CPU: Processor Core ID:
>> CPU %d/0x%x -> Node %d
>
> why?
Someone asked that they be removed?
The intent of the patch was to remove repetitious per cpu printouts where the
information is easily available via some other means, which is the case of the
above 3 lines. Would you prefer they stay as KERN_DEBUG or pr_debug lines?
(I had it this way in the first version but then was told that the messages were
not needed.)
Thanks,
Mike
next prev parent reply other threads:[~2009-11-13 13:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-12 17:19 [PATCH 0/7] Limit console output by suppressing repetitious messages Mike Travis
2009-11-12 17:19 ` [PATCH 1/7] x86: Limit the number of processor bootup messages Mike Travis
2009-11-12 18:09 ` Ingo Molnar
2009-11-12 20:05 ` Mike Travis
2009-11-13 9:52 ` Ingo Molnar
2009-11-13 13:43 ` Mike Travis
2009-11-12 22:10 ` Yinghai Lu
2009-11-13 13:46 ` Mike Travis [this message]
2009-11-13 21:58 ` Yinghai Lu
2009-11-12 17:19 ` [PATCH 2/7] ACPI: Limit the number of per cpu ACPI " Mike Travis
2009-11-12 21:02 ` David Rientjes
2009-11-12 21:19 ` Mike Travis
2009-11-12 21:28 ` David Rientjes
2009-11-13 13:53 ` Mike Travis
2009-11-12 17:19 ` [PATCH 3/7] INIT: Limit the number of per cpu INIT " Mike Travis
2009-11-12 21:06 ` David Rientjes
2009-11-12 21:20 ` Mike Travis
2009-11-12 17:19 ` [PATCH 4/7] firmware: Limit the number of per cpu firmware messages during bootup Mike Travis
2009-11-12 17:19 ` [PATCH 5/7] x86: Limit the number of per cpu MCE bootup messages Mike Travis
2009-11-12 17:19 ` [PATCH 6/7] sched: Limit the number of scheduler debug messages Mike Travis
2009-11-12 17:19 ` [PATCH 7/7] x86: Limit number of per cpu TSC sync messages Mike Travis
2009-11-12 20:48 ` [patch] x86: reduce srat verbosity in the kernel log David Rientjes
2009-11-13 9:53 ` Ingo Molnar
2009-11-13 10:02 ` David Rientjes
2009-11-13 10:13 ` Ingo Molnar
2009-11-13 10:29 ` David Rientjes
2009-11-13 10:57 ` Ingo Molnar
2009-11-20 18:37 ` Pavel Machek
2009-11-20 18:58 ` Mike Travis
2009-11-12 22:16 ` [PATCH 0/7] Limit console output by suppressing repetitious messages Yinghai Lu
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=4AFD6325.8000000@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox