From: Ingo Molnar <mingo@elte.hu>
To: Mike Travis <travis@sgi.com>
Cc: Andi Kleen <ak@linux.intel.com>,
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>,
Greg Kroah-Hartman <gregkh@suse.de>,
Yinghai Lu <yinghai@kernel.org>, "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 <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86_64: Limit the number of processor bootup messages
Date: Wed, 4 Nov 2009 11:24:36 +0100 [thread overview]
Message-ID: <20091104102436.GB15086@elte.hu> (raw)
In-Reply-To: <4AF0C958.6010103@sgi.com>
* Mike Travis <travis@sgi.com> wrote:
>
> ...
>>> So please go with the simple solution i suggested days ago: print
>>> stuff on the boot CPU but after that only a single line per AP CPU.
>>>
>>> Ingo
>>
>
> Hi Ingo,
>
> Here is some timing info I collected... Would you accept the first
> format (line per node) as a compromise?
>
> (Note there will be 256 node systems w/4096 threads as well as
> 512 node systems w/HT disabled thus still 4096 threads.)
>
> Btw, I think we should keep the processor summary as it does show some
> useful information. Agreed?
>
> (... I'll clean up the BogoMIPS line a bit:
>
> BogoMIPS(lpj): MIN xxx (yyy) AVG xxx (yyy) MAX xxx (yyy)
> ...)
>
> Thanks,
> Mike
>
> 64 Nodes/512 cores/1024 threads...
>
> By Node:
> 1 [ 27.998414] Booting Node 0, Processors 1-7,512-519
> 2 [ 28.645066] Booting Node 1, Processors 8-15,520-527
> 3 [ 29.389359] Booting Node 2, Processors 16-23,528-535
> 4 [ 30.160646] Booting Node 3, Processors 24-31,536-543
> ...
> 62 [ 75.013459] Booting Node 61, Processors 488-495,1000-1007
> 63 [ 75.789663] Booting Node 62, Processors 496-503,1008-1015
> 64 [ 76.565430] Booting Node 63, Processors 504-511,1016-1023
> 65 [ 126.860204] Brought up 1024 CPUs
Yeah, this portion certainly looks good. The important thing is to make
this the default - i.e. we dont want some weird switch (or other hw
dependent flaggery) to turn on two styles of bootup output.
We have trouble keeping a single variant sane already, we definitely
dont want to have multiple variants.
> 66 [ 126.865392] Summary Processor Information for CPUS: 0-143,256-383,448-655,768-895,960-1023
> 67 [ 126.876033] Genuine Intel(R) CPU 0000 @ 2.13GHz stepping 04
> 68 [ 126.881404] BogoMIPS: MIN 3980.53 MAX 4268.28 AVG 4265.85
> 69 [ 126.888032] Loops/Jiffy: MIN 7961074 MAX 8536570 AVG 8531701
> 70 [ 126.896875] Summary Processor Information for CPUS: 144-239,384-447,656-751,896-959
> 71 [ 126.904032] Intel(R) Xeon(R) CPU X7560 @ 2.27GHz stepping 05
> 72 [ 126.913404] BogoMIPS: MIN 4528.51 MAX 4762.75 AVG 4535.89
> 73 [ 126.920032] Loops/Jiffy: MIN 9057030 MAX 9525505 AVG 9071785
> 74 [ 126.924217] Summary Processor Information for CPUS: 240-255,752-767
> 75 [ 126.932032] Genuine Intel(R) CPU 0000 @ 2.13GHz stepping 03
> 76 [ 126.937404] BogoMIPS: MIN 4267.31 MAX 4268.24 AVG 4267.66
> 77 [ 126.944032] Loops/Jiffy: MIN 8534632 MAX 8536490 AVG 8535338
> 78 [ 126.952425] Total of 1024 processors activated (4454702.72 BogoMIPS).
4.4 million bogomips. Nice ;-)
>
> By CPU:
> 1 [ 28.010255] Booting Processor 1 APIC 0x2 ip 0x6000
> 2 [ 28.106191] Booting Processor 2 APIC 0x4 ip 0x6000
> 3 [ 28.204705] Booting Processor 3 APIC 0x6 ip 0x6000
> 4 [ 28.300709] Booting Processor 4 APIC 0x10 ip 0x6000
> 5 [ 28.400707] Booting Processor 5 APIC 0x12 ip 0x6000
> ...
> 1020 [ 131.440341] Booting Processor 1020 APIC 0x7f1 ip 0x6000
> 1021 [ 131.544366] Booting Processor 1021 APIC 0x7f3 ip 0x6000
> 1022 [ 131.648354] Booting Processor 1022 APIC 0x7f5 ip 0x6000
> 1023 [ 131.752350] Booting Processor 1023 APIC 0x7f7 ip 0x6000
> 1024 [ 131.852202] Brought up 1024 CPUs
i'd suggest some cleanups to this single line output.
The 'ip' printout is very lame an comes from ancient times, from our
first attempts to boot Linux in SMP mode on dual 100 MHz pentia ;-)
Something like:
Booting CPU #1020 ... ok.
Would be more than enough. Any other info can be made a debug boot flag,
dependent on apic=verbose.
Please send a new iteration of the arch/x86 (and scheduler/timer)
patches in a separate series instead of mixed into this thread.
Thanks,
Ingo
next prev parent reply other threads:[~2009-11-04 10:25 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20091023233743.439628000@alcatraz.americas.sgi.com>
2009-10-23 23:37 ` [PATCH 1/8] SGI x86_64 UV: Add limit console output function Mike Travis
2009-10-24 1:09 ` Frederic Weisbecker
2009-10-26 17:55 ` Mike Travis
2009-11-02 14:15 ` Frederic Weisbecker
2009-10-26 7:02 ` Andi Kleen
2009-10-26 16:10 ` Steven Rostedt
2009-10-26 18:05 ` Mike Travis
2009-10-26 18:51 ` Steven Rostedt
2009-10-26 18:03 ` Mike Travis
2009-10-26 21:55 ` Andi Kleen
2009-10-26 22:07 ` Mike Travis
2009-10-30 19:25 ` [PATCH] x86_64: Limit the number of processor bootup messages Mike Travis
2009-10-30 19:54 ` David Rientjes
2009-10-30 20:39 ` Mike Travis
2009-10-30 23:30 ` David Rientjes
2009-10-31 0:27 ` Mike Travis
2009-11-02 11:11 ` Andi Kleen
2009-11-02 19:21 ` Mike Travis
2009-11-02 19:34 ` Ingo Molnar
2009-11-02 20:32 ` Mike Travis
2009-11-04 0:22 ` Mike Travis
2009-11-04 10:24 ` Ingo Molnar [this message]
2009-11-04 10:31 ` Ingo Molnar
2009-11-12 22:22 ` Dave Jones
2009-11-12 22:57 ` H. Peter Anvin
2009-11-12 23:15 ` Dave Jones
2009-11-13 8:03 ` Ingo Molnar
2009-11-13 8:11 ` H. Peter Anvin
2009-11-13 8:18 ` [tip:x86/debug] x86: Remove the CPU cache size printk's tip-bot for Dave Jones
2009-11-13 22:38 ` [PATCH] x86: Remove CPU cache size output for non-Intel too Roland Dreier
2009-11-13 22:52 ` Dave Jones
2009-11-14 0:54 ` [tip:x86/debug] " tip-bot for Roland Dreier
2009-11-13 16:10 ` [PATCH] x86_64: Limit the number of processor bootup messages Mike Travis
2009-11-14 0:53 ` Ingo Molnar
2009-10-23 23:37 ` [PATCH 2/8] SGI x86_64 UV: " Mike Travis
2009-10-26 7:26 ` Andi Kleen
2009-10-23 23:37 ` [PATCH 3/8] SGI x86_64 UV: Limit the number of number of SRAT messages Mike Travis
2009-10-26 7:04 ` Andi Kleen
2009-10-26 18:08 ` Mike Travis
2009-10-27 15:24 ` Mike Travis
2009-10-27 19:45 ` David Rientjes
2009-10-27 20:00 ` Mike Travis
2009-10-27 20:25 ` [patch] x86: reduce srat verbosity in the kernel log David Rientjes
2009-10-27 20:42 ` Mike Travis
2009-10-27 20:48 ` David Rientjes
2009-10-27 23:02 ` Mike Travis
2009-10-28 3:29 ` Andi Kleen
2009-10-28 4:08 ` David Rientjes
2009-10-28 3:53 ` Yinghai Lu
2009-10-28 4:08 ` David Rientjes
2009-10-27 20:55 ` Cyrill Gorcunov
2009-10-27 21:06 ` David Rientjes
2009-10-27 21:10 ` Cyrill Gorcunov
2009-10-28 3:32 ` Andi Kleen
2009-10-28 4:08 ` David Rientjes
2009-10-28 4:11 ` Andi Kleen
2009-10-28 4:53 ` [patch v2] " David Rientjes
2009-10-28 5:19 ` Andi Kleen
2009-10-28 5:24 ` David Rientjes
2009-11-10 21:08 ` David Rientjes
2009-11-10 21:33 ` Ingo Molnar
2009-11-10 21:42 ` Yinghai Lu
2009-11-10 21:57 ` Ingo Molnar
2009-11-10 23:09 ` Mike Travis
2009-11-12 20:56 ` David Rientjes
2009-11-12 21:14 ` Mike Travis
2009-11-12 21:20 ` David Rientjes
2009-10-28 17:02 ` [patch] " Mike Travis
2009-10-28 20:52 ` David Rientjes
2009-10-28 21:03 ` Mike Travis
2009-10-28 21:06 ` David Rientjes
2009-10-28 21:35 ` Mike Travis
2009-10-28 21:46 ` David Rientjes
2009-10-28 22:36 ` Mike Travis
2009-10-29 8:21 ` David Rientjes
2009-10-29 16:34 ` Mike Travis
2009-10-29 19:06 ` David Rientjes
2009-10-27 20:16 ` [PATCH 3/8] SGI x86_64 UV: Limit the number of number of SRAT messages Cyrill Gorcunov
2009-10-27 20:23 ` Mike Travis
2009-10-27 20:33 ` Cyrill Gorcunov
2009-10-23 23:37 ` [PATCH 4/8] SGI x86_64 UV: Limit the number of ACPI messages Mike Travis
2009-10-24 3:29 ` Bjorn Helgaas
2009-10-26 18:15 ` Mike Travis
2009-10-26 22:47 ` Thomas Renninger
2009-10-26 21:25 ` Mike Travis
2009-10-27 15:27 ` Mike Travis
2009-10-27 15:51 ` Bjorn Helgaas
2009-10-23 23:37 ` [PATCH 5/8] SGI x86_64 UV: Limit the number of firmware messages Mike Travis
2009-10-23 23:37 ` [PATCH 6/8] SGI x86_64 UV: Limit the number of microcode messages Mike Travis
2009-10-24 20:09 ` Dmitry Adamushko
2009-10-24 21:09 ` Tigran Aivazian
2009-10-24 22:45 ` Dmitry Adamushko
2009-10-25 16:37 ` Ingo Molnar
2009-10-25 17:11 ` Arjan van de Ven
2009-10-25 17:27 ` Ingo Molnar
2009-10-26 18:33 ` Mike Travis
2009-10-26 18:29 ` Mike Travis
2009-10-26 18:29 ` Mike Travis
2009-10-26 20:11 ` Dmitry Adamushko
2009-10-27 15:21 ` Mike Travis
2009-10-26 18:25 ` Mike Travis
2009-10-26 19:27 ` Borislav Petkov
2009-10-30 19:40 ` [PATCH] x86_64: " Mike Travis
2009-10-26 18:24 ` [PATCH 6/8] SGI x86_64 UV: " Mike Travis
2009-10-26 18:18 ` Mike Travis
2009-10-26 7:05 ` Andi Kleen
2009-10-26 18:34 ` Mike Travis
2009-10-23 23:37 ` [PATCH 7/8] SGI x86_64 UV: Limit the number of scheduler debug messages Mike Travis
2009-10-23 23:37 ` [PATCH 8/8] SGI x86_64 UV: Limit the number of cpu is down messages 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=20091104102436.GB15086@elte.hu \
--to=mingo@elte.hu \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.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=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=travis@sgi.com \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/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
all inboxes | Powered by JetHome®