linux-kernel - Re: [PATCH v1 0/2] x86/smp: Fix power regression introduced by commit 96040f7273e2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0iCesz+jhnxeBOV6-7LLViOnzi+JFXcsOw-dqK=81d8FA@mail.gmail.com>
Date: Fri, 30 May 2025 18:59:13 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, x86 Maintainers <x86@...nel.org>, 
	LKML <linux-kernel@...r.kernel.org>, Linux PM <linux-pm@...r.kernel.org>, 
	Len Brown <lenb@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...e.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, 
	Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>, 
	"Gautham R. Shenoy" <gautham.shenoy@....com>, Ingo Molnar <mingo@...hat.com>, 
	Todd Brandt <todd.e.brandt@...ux.intel.com>
Subject: Re: [PATCH v1 0/2] x86/smp: Fix power regression introduced by commit 96040f7273e2

On Fri, May 30, 2025 at 11:18 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Fri, May 30, 2025 at 10:07 AM Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > On Thu, May 29, 2025 at 11:38:05AM +0200, Rafael J. Wysocki wrote:
> >
> > > First off, I'm not sure if all of the requisite things are ready then
> > > (sysfs etc.).
> >
> > Pretty much everything is already running at early_initcall(). Sysfs
> > certainly is.
> >
> > > We may end up doing this eventually, but it may not be straightforward.
> > >
> > > More importantly, this is not a change for 6.15.y (y > 0).
> >
> > Seriously, have you even tried?
> >
> > AFAICT the below is all that is needed.  That boots just fine on the one
> > randon system I tried, and seems to still work.
> >
> > And this is plenty small enough to go into 6.15.y
>
> But there is still intel_idle_init() which is device_initcall() ATM
> and this needs to be tested on other arches too.

intel_idle_init() depends on ACPI which initializes via a
subsys_initcall() and doing that earlier would mean a major redesign.

Pretty much same for reordering APs initialization past ACPI initialization.

One more option is to kick the "dead" SMT siblings after the idle
driver initializes and let them do "play dead" again, but who'd be
responsible for doing that?