[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AFD6325.8000000@sgi.com>
Date: Fri, 13 Nov 2009 05:46:13 -0800
From: Mike Travis <travis@....com>
To: Yinghai Lu <yhlu.kernel@...il.com>
CC: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Roland Dreier <rdreier@...co.com>,
Randy Dunlap <rdunlap@...otime.net>, Tejun Heo <tj@...nel.org>,
Andi Kleen <andi@...stfloor.org>,
Greg Kroah-Hartman <gregkh@...e.de>,
"H. Peter Anvin" <hpa@...or.com>,
David Rientjes <rientjes@...gle.com>,
Steven Rostedt <rostedt@...dmis.org>,
Rusty Russell <rusty@...tcorp.com.au>,
Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
Jack Steiner <steiner@....com>,
Frederic Weisbecker <fweisbec@...il.com>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/7] x86: Limit the number of processor bootup messages
Yinghai Lu wrote:
> On Thu, Nov 12, 2009 at 9:19 AM, Mike Travis <travis@....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
--
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