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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.