public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Roland Dreier <rdreier@cisco.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Andi Kleen <ak@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] x86, mce: short output of MCE banks ownership information
Date: Thu, 29 Oct 2009 09:07:05 -0700	[thread overview]
Message-ID: <4AE9BDA9.3030804@sgi.com> (raw)
In-Reply-To: <4AE93B42.5040605@jp.fujitsu.com>

I have a patch coming that summarizes the Booting processor msgs and
the Processor information messages:

The first increases the start count by a power of 2 so 4096 cpus
would only need 12 lines.

[   25.388280] Booting Processors 1-7,320-327, Nodes 0-0
[   26.064742] Booting Processors 8-15,328-335, Nodes 1-1
[   26.837006] Booting Processors 16-31,336-351, Nodes 2-3
[   28.440427] Booting Processors 32-63,352-383, Nodes 4-7
[   31.640450] Booting Processors 64-127,384-447, Nodes 8-15
[   38.041430] Booting Processors 128-255,448-575, Nodes 16-31
[   50.917504] Booting Processors 256-319,576-639, Nodes 32-63 

(the last line has a slight error in that actually only nodes 32-39
were starting.  Btw, the processor numbers are correct, according
to the Intel spec.)

and

[  103.860206] Summary Processor information for CPUS: 0-639
[  103.864032] Genuine Intel(R) CPU             0000 @ 2.13GHz stepping 04
[  103.873403] CPU: L1 I cache: 32K, L1 D cache: 32K
[  103.877885] CPU: L2 cache: 256K
[  103.880032] CPU: L3 cache: 24576K
[  103.884032] MIN 4266.68 BogoMIPS (lpj=8533378)
[  103.888032] MAX 4267.70 BogoMIPS (lpj=8535412)
[  103.896248] Total of 640 processors activated (2731043.30 BogoMIPS).

This summary looks for different cpu types, steppings and cache sizes.

                                                         
Hidetoshi Seto wrote:
> Roland Dreier wrote:
>> Seems OK, but I think it would be even more useful to find a way to
>> print fewer lines of output; with CPUs that will be released shortly, a
>> system with 64 or even 128 logical CPUs will not be will not be that
>> exotic, and producing 128 lines of kernel log output for debugging
>> information that is rarely used and where the same info can be expressed
>> in 2 or 3 lines is silly-looking (and very annoying on a 57600 bps
>> serial console!).
> 
> Thanks for your review!
> 
> I think we could some effort like this for other messages during
> CPU initialization.
> 
> For example I googled a full dmesg of recent hardware:
>   http://www.gossamer-threads.com/lists/linux/kernel/1134265
> It shows that the lines like:
>    :
>   Booting processor 1 APIC 0x2 ip 0x6000
>   Initializing CPU#1 
>   Calibrating delay using timer specific routine.. 5344.67 BogoMIPS (lpj=2672337) 
>   CPU: Physical Processor ID: 0 
>   CPU: Processor Core ID: 1 
>   CPU: L1 I cache: 32K, L1 D cache: 32K 
>   CPU: L2 cache: 256K 
>   CPU: L3 cache: 8192K 
>   mce: CPU supports 9 MCE banks 
>   CPU1: Thermal monitoring enabled (TM1) 
>   CPU 1 MCA banks CMCI:2 CMCI:3 CMCI:5 SHD:6 SHD:8 
>   x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106 
>   CPU1: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 
>   Skipping synchronization checks as TSC is reliable. 
>    :
> are that printed for every cpu.
> 
> We already eliminated "mce: CPU supports X MCE banks" in this repeat
> and now going to compress "CPU X MCA banks ..." line.
> 
> I suppose:
>   - Cache information can be compressed too, could be in one line.
>   - Usually model name (and also cache size) will be same on all cpu.
> 
> I can understand that it is better to avoid printing same lines
> again and again.  But there are more redundant messages...
> 
> Maybe there would be more desirable ways, but I think that
> "compress messages shorter to bear heavy repeating" will be
> a good way at this time.
> 
> 
> Thanks,
> H.Seto

  parent reply	other threads:[~2009-10-29 16:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-29  3:38 [PATCH] x86, mce: short output of MCE banks ownership information Hidetoshi Seto
2009-10-29  3:45 ` Roland Dreier
2009-10-29  6:50   ` Hidetoshi Seto
2009-10-29  7:34     ` Ingo Molnar
2009-10-29  8:27       ` Hidetoshi Seto
2009-10-29  9:09         ` Ingo Molnar
2009-10-29 16:07     ` Mike Travis [this message]
2009-10-29 16:00 ` 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=4AE9BDA9.3030804@sgi.com \
    --to=travis@sgi.com \
    --cc=ak@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rdreier@cisco.com \
    --cc=seto.hidetoshi@jp.fujitsu.com \
    --cc=tglx@linutronix.de \
    --cc=x86@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