From: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
To: Roland Dreier <rdreier@cisco.com>
Cc: 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>,
Mike Travis <travis@sgi.com>
Subject: Re: [PATCH] x86, mce: short output of MCE banks ownership information
Date: Thu, 29 Oct 2009 15:50:42 +0900 [thread overview]
Message-ID: <4AE93B42.5040605@jp.fujitsu.com> (raw)
In-Reply-To: <adaaaza6exw.fsf@cisco.com>
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
next prev parent reply other threads:[~2009-10-29 6:51 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 [this message]
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
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=4AE93B42.5040605@jp.fujitsu.com \
--to=seto.hidetoshi@jp.fujitsu.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=tglx@linutronix.de \
--cc=travis@sgi.com \
--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