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

From: Borislav Petkov
Date: Fri Oct 18 2019 - 15:45:07 EST

On Fri, Oct 18, 2019 at 11:02:57AM -0700, Luck, Tony wrote:
> So what should we do next?

I was simply keying off this statement of yours:

"Depending on what we end up with from Srinivas ... we may want to
reconsider the severity."

and I don't think that having KERN_CRIT severity for those messages
makes any sense. That's why I was hinting at us organizing and defining
our handling of thermal interrupt events properly so that we handle
those things correctly and not have people look at dmesg.

> 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.

See above. All resulted from me stating that KERN_CRIT messages or any
type of messages in dmesg as a result of hitting thermal limits are
useless. If we wanna handle those properly, then we need to do something

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

I think we agree on doing the dynamic threshold determination, no?

If, as Srinivas points out in another mail, the purpose of those
messages is when one wants to examine what happened, then fine. If we
must do more, then see above.

Does that make more sense?