Messages in this thread | | | Date | Fri, 18 Oct 2019 21:45:03 +0200 | From | Borislav Petkov <> | Subject | Re: [PATCH 1/2] x86, mce, therm_throt: Optimize logging of thermal throttle messages |
| |
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 else.
> 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?
-- Regards/Gruss, Boris.
https://people.kernel.org/tglx/notes-about-netiquette
| |