[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250429210650.GD4439@noisy.programming.kicks-ass.net>
Date: Tue, 29 Apr 2025 23:06:50 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: carlos.bilbao@...nel.org, tglx@...utronix.de, seanjc@...gle.com,
jan.glauber@...il.com, bilbao@...edu, 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
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..
Powered by blists - more mailing lists