From: Peter Zijlstra <peterz@infradead.org>
To: Carlos Bilbao <bilbao@vt.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
seanjc@google.com, carlos.bilbao@kernel.org, tglx@linutronix.de,
jan.glauber@gmail.com, pmladek@suse.com, jani.nikula@intel.com,
linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
takakura@valinux.co.jp, john.ogness@linutronix.de,
x86@kernel.org
Subject: Re: [PATCH v3 0/2] Reduce CPU consumption after panic
Date: Thu, 1 May 2025 10:55:28 +0200 [thread overview]
Message-ID: <20250501085528.GR4439@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <2e075491-538c-40e1-8086-5405aecb2779@vt.edu>
On Wed, Apr 30, 2025 at 01:54:11PM -0500, Carlos Bilbao wrote:
> > All that said... the default more or less does for(;;) { mdelay(100) },
> > if you have a modern chip that should not end up using much power at
> > all. That should end up in delay_halt_tpause() or delay_halt_mwaitx()
> > (depending on you being on Intel or AMD). And spend most its time in
> > deep idle states.
> >
> > Is something not working?
>
> Well, in my experiments, that’s not what happened -- halting the CPU in VMs
> reduced CPU usage by around 70%.
Because you're doing VMs, and VMs create problems where there weren't
any before. IOW you get to keep the pieces.
Specifically, VMs do VMEXIT on HLT and this is what's working for you.
On real hardware though, HLT gets you C1, while both TPAUSE and MWAITX
can probably get you deeper C states. As such, HLT is probably a
regression on power.
> How would folks feel about adding something like
> /proc/sys/kernel/halt_after_panic, disabled by default? It would help in
> the Linux use cases I care about (e.g., virtualized environments), without
> affecting others.
What's wrong with any of the existing options? Fact remains you need to
configure your VMs properly.
next prev parent reply other threads:[~2025-05-01 8:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 15:06 [PATCH v3 0/2] Reduce CPU consumption after panic carlos.bilbao
2025-04-29 15:06 ` [PATCH v3 1/2] panic: Allow for dynamic custom behavior " carlos.bilbao
2025-04-29 15:06 ` [PATCH v3 2/2] x86/panic: Add x86_panic_handler as default post-panic behavior carlos.bilbao
2025-04-29 20:39 ` [PATCH v3 0/2] Reduce CPU consumption after panic Andrew Morton
2025-04-29 20:17 ` Carlos Bilbao
2025-04-29 22:53 ` Andrew Morton
2025-04-29 21:39 ` Carlos Bilbao
2025-04-29 21:06 ` Peter Zijlstra
2025-04-29 20:32 ` Carlos Bilbao
2025-04-29 22:10 ` Peter Zijlstra
2025-04-29 20:52 ` Carlos Bilbao
2025-04-30 8:48 ` Peter Zijlstra
2025-04-30 15:59 ` Sean Christopherson
2025-04-30 18:54 ` Carlos Bilbao
2025-05-01 8:55 ` Peter Zijlstra [this message]
2025-05-07 19:49 ` Carlos Bilbao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250501085528.GR4439@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=bilbao@vt.edu \
--cc=carlos.bilbao@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jan.glauber@gmail.com \
--cc=jani.nikula@intel.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=seanjc@google.com \
--cc=takakura@valinux.co.jp \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.