[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <433c6561-353e-4752-b9cf-155e49e62e63@vt.edu>
Date: Tue, 29 Apr 2025 15:32:56 -0500
From: Carlos Bilbao <bilbao@...edu>
To: Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: carlos.bilbao@...nel.org, tglx@...utronix.de, seanjc@...gle.com,
jan.glauber@...il.com, pmladek@...e.com, jani.nikula@...el.com,
linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
takakura@...inux.co.jp, john.ogness@...utronix.de, x86@...nel.org
Subject: Re: [PATCH v3 0/2] Reduce CPU consumption after panic
Hey Peter,
On 4/29/25 16:06, Peter Zijlstra wrote:
> On Tue, Apr 29, 2025 at 01:39:41PM -0700, Andrew Morton wrote:
>> (cc more x86 people)
>>
>> On Tue, 29 Apr 2025 10:06:36 -0500 carlos.bilbao@...nel.org wrote:
>>
>>> From: Carlos Bilbao <carlos.bilbao@...nel.org>
>>>
>>> Provide a priority-based mechanism to set the behavior of the kernel at
>>> the post-panic stage -- the current default is a waste of CPU except for
>>> cases with console that generate insightful output.
>>>
>>> In v1 cover letter [1], I illustrated the potential to reduce unnecessary
>>> CPU resources with an experiment with VMs, reducing more than 70% of CPU
>>> usage. The main delta of v2 [2] was that, instead of a weak function that
>>> archs can overwrite, we provided a flexible priority-based mechanism
>>> (following suggestions by Sean Christopherson), panic_set_handling().
>>>
>>
>> An effect of this is that the blinky light will never again occur on
>> any x86, I think? I don't know what might the effects of changing such
>> longstanding behavior.
>>
>> Also, why was the `priority' feature added? It has no effect in this
>> patchset.
>
> It does what now, and why?
>
> Not being copied on anything, the first reaction is, its panic, your
> machine is dead, who cares about power etc..
Thanks for taking the time to look into my patch set!
Yes, the machine is effectively dead, but as things stand today,
it's still drawing resources unnecessarily.
Who cares? An example, as mentioned in the cover letter, is Linux running
in VMs. Imagine a scenario where customers are billed based on CPU usage --
having panicked VMs spinning in useless loops wastes their money. In shared
envs, those wasted cycles could be used by other processes/VMs. But this
is as much about the cloud as it is for laptops/embedded/anywhere -- Linux
should avoid wasting resources wherever possible.
Thanks,
Carlos
Powered by blists - more mailing lists