From: Borislav Petkov <bp@amd64.org>
To: Tony Luck <tony.luck@intel.com>
Cc: "Yu, Fenghua" <fenghua.yu@intel.com>,
H Peter Anvin <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
"Brown, Len" <len.brown@intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH] x86/mcheck/therm_throt.c: Don't log power limit and package level thermal throttle event in mce log
Date: Tue, 6 Dec 2011 20:56:30 +0100 [thread overview]
Message-ID: <20111206195630.GH20445@aftab> (raw)
In-Reply-To: <CA+8MBb+v_HJ=odHMTZUP_LuNkAj=dHPC28i3HWAkemW7CN=hMw@mail.gmail.com>
On Tue, Dec 06, 2011 at 11:26:03AM -0800, Tony Luck wrote:
> On Tue, Dec 6, 2011 at 11:06 AM, Borislav Petkov <bp@amd64.org> wrote:
> > I can see all that. Still, I'm questioning the need for those printks. A
> > user application polling the counters is a much better solution, IMHO,
> > than spamming the logs. IOW, is there a strong reason to have this -
> > even ratelimited - information in the logs and unnerve users, or, would
> > it be better to collect this info somewhere queitly and present it only
> > when something requests it?
>
> Striking the right balance here is hard - if one has a BIOS that set the
> thresholds at "interesting" values - then you certainly don't want to the
> console to be spammed with a lot of useless junk.
>
> But if there is a real problem - then having someone tell you later that
> you should have been checking some obscure file in /sys to see that
> some thermal/power limit events were being seen may not go over very
> well.
Agreed.
> When we have some comprehensive system health monitoring daemon that
> does check these files, and can be configured to raise suitable
> alerts, then the printks can go away.
Ok, that makes sense, actually. A follow-up: what recovery handling are
you thinking of here, maybe force-suspend the box or disable boosting or
whatever?
All I'm saying is, how does one take care of the real problem you
mention above? I hope you're seeing my point here: I'm simply
questioning the fact whether printk's are optimal here.
But, before we completely drift off, to answer your original question:
I'm fine with the patch, it is Intel-only anyway so if you guys feel it
is a step in the right direction, you can have my ACK.
The printks story sounds like something we'll not be solving today
anyway, so... :-)
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
next prev parent reply other threads:[~2011-12-06 19:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-14 21:11 [PATCH] x86/mcheck/therm_throt.c: Don't log power limit and package level thermal throttle event in mce log Fenghua Yu
2011-12-05 13:18 ` Borislav Petkov
2011-12-05 22:18 ` Luck, Tony
2011-12-06 15:31 ` Borislav Petkov
2011-12-06 17:48 ` Yu, Fenghua
2011-12-06 19:06 ` Borislav Petkov
2011-12-06 19:26 ` Tony Luck
2011-12-06 19:56 ` Borislav Petkov [this message]
2011-12-06 19:27 ` Yu, Fenghua
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=20111206195630.GH20445@aftab \
--to=bp@amd64.org \
--cc=akpm@linux-foundation.org \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.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.