mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®