linux-kernel - Re: [PATCH v5 1/3] x86/smp: Allow calling mwait_play

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: <9a918226-4f93-4ee5-8673-20d82802f126@linux.intel.com>
Date: Wed, 27 Nov 2024 09:32:38 +0100
From: Patryk Wlazlyn <patryk.wlazlyn@...ux.intel.com>
To: "Gautham R. Shenoy" <gautham.shenoy@....com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
 rafael.j.wysocki@...el.com, peterz@...radead.org,
 dave.hansen@...ux.intel.com, tglx@...utronix.de, len.brown@...el.com,
 artem.bityutskiy@...ux.intel.com
Subject: Re: [PATCH v5 1/3] x86/smp: Allow calling mwait_play_dead with an
 arbitrary hint

> Hello Patryk,
>
> Apologies for what may appear as bikeshedding, after this patch, the
> cpuidle code still won't call any mwait based play dead loop since the
> support for enter_dead for FFh based idle states in acpi_idle and
> intel_idle only gets added in Patches 2 and 3.
>
> Does it make sense to split this Patch 1 into 2 patches : 1/4 and 4/4
>
> 1/4 just introduces the mwait_play_dead_with_hint() helper which will
> be used by patches 2 and 3.
>
> 4/4 get rids of the of logic to find the deepest state from
> mwait_play_dead() and modifies native_play_dead() to call
> cpuidle_play_dead() followed by hlt_play_dead() thus removing any
> reference to mwait_play_dead(). Optionally you can even rename
> mwait_play_dead_with_hints() to mwait_play_dead().
>
> That way the changelog that you have for this patch can be used in 4/4
> since with the addition of play_dead support for FFh states in both
> acpi_idle and intel_idle via patches 2 and 3, the logic to find the
> deepest ffh state in mwait_play_dead() is no longer required.
>
> Thoughts ?

Yeah, makes sense. I just wanted to simplify, but at some point crossed my mind
that submitting it like you suggested may be better. I am going to split that
if I don't see any objections.