linux-kernel - Re: [PATCH 1/2] x86, mce, therm_throt: Optimize logging of thermal throttle messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Oct 2019 11:02:57 -0700
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.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 03:23:09PM +0200, Borislav Petkov wrote:
> 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.

Recap:

We are starting from a place where the kernel prints a message.

Patch already in flight to reduce the severity of the message
(since users are seeing it, and find it annoying/unhelpful that
it has such a high severity).

Srinivas has asserted that in many cases we can eliminate the
message. But wants to keep the message if it seems that there
is something really wrong.

---

So what should we do next?  I don't think there is much by way
of actions that the kernel should take.  While we could stop
scheduling processes, the h/w and f/w have better tools to
reduce frequency, inject idle cycles, speed up fans, etc.
If you do have ideas ... then please share.

So this thread is now about doing the proper definition of
what we actions Linux should take.

Proposal on the table is the algoritm embodied in Srinivas'
patch (which originated from Alan Cox).

I.e.
1) ignore short excursions above this threshold.
2) Print a message for persistent problems.
3) Keep a record of total time spent above threshold.

If that's a reasonable approach, the we just need to come
up with a way to define "short excursion" (which might be
platform dependent). If someone has a brilliant idea on
how to do that, we can use it. If not we #define a number.

If it isn't reasonable ... then propose something better.

-Tony