[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191018132309.GD17053@zn.tnic>
Date: Fri, 18 Oct 2019 15:23:09 +0200
From: Borislav Petkov <bp@...en8.de>
To: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Cc: "Luck, Tony" <tony.luck@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"hpa@...or.com" <hpa@...or.com>,
"bberg@...hat.com" <bberg@...hat.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"hdegoede@...hat.com" <hdegoede@...hat.com>,
"ckellner@...hat.com" <ckellner@...hat.com>
Subject: Re: [PATCH 1/2] x86, mce, therm_throt: Optimize logging of thermal
throttle messages
On Fri, Oct 18, 2019 at 05:26:36AM -0700, Srinivas Pandruvada wrote:
> Server/desktops generally rely on the embedded controller for FAN
> control, which kernel have no control. For them this warning helps to
> either bring in additional cooling or fix existing cooling.
How exactly does this warning help? A detailed example please.
> If something needs to force throttle from kernel, then we should use
> some offset from the max temperature (aka TJMax), instead of this
> warning threshold. Then we can use idle injection or change duty cycle
> of CPU clocks.
Yes, as I said, all this needs to be properly defined first. That is,
*if* there's even need for reacting to thermal interrupts in the kernel.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists