linux-kernel - Re: [PATCH v3 0/6] PM: QoS: Introduce a CPU system wakeup QoS limit for s2idle

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: <CAJZ5v0hz+gMnnPVX=uT3dh0tSoaATVOzwrhdBoupeYFgo6Rqkw@mail.gmail.com>
Date: Mon, 24 Nov 2025 19:27:35 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: "Rafael J . Wysocki" <rafael@...nel.org>, linux-pm@...r.kernel.org, 
	Vincent Guittot <vincent.guittot@...aro.org>, Peter Zijlstra <peterz@...radead.org>, 
	Kevin Hilman <khilman@...libre.com>, Pavel Machek <pavel@...nel.org>, Len Brown <len.brown@...el.com>, 
	Daniel Lezcano <daniel.lezcano@...aro.org>, Maulik Shah <quic_mkshah@...cinc.com>, 
	Prasad Sodagudi <psodagud@...cinc.com>, Dhruva Gole <d-gole@...com>, 
	Deepti Jaggi <quic_djaggi@...cinc.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/6] PM: QoS: Introduce a CPU system wakeup QoS limit
 for s2idle

On Fri, Nov 21, 2025 at 11:03 AM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> Changes in v3:
>         - Take new the new QoS limit into account for cpuidle too (Rafael).
>         - Add a new Kconfig for the new QoS interface (Rafael)
>         - Improved the documentation (Dhruva)
>         - Clarified commit messages and added acks.
>
> Changes in v2:
>         - Limit the new QoS to CPUs  and make some corresponding renaming of the
>         functions along with name of the device node for user space.
>         - Make sure we deal with the failure/error path correctly when there are
>         no state available for s2idle.
>         - Add documentation.
>
> Some platforms supports multiple low power states for CPUs that can be used
> when entering system-wide suspend and s2idle in particular. Currently we are
> always selecting the deepest possible state for the CPUs, which can break the
> system wakeup latency constraint that may be required for a use case.
>
> Therefore, this series suggests to introduce a new interface for user space,
> allowing us to specify the CPU system wakeup QoS limit. The QoS limit is then
> taken into account when selecting a suitable low power state for s2idle/cpuidle.
>
> Kind regards
> Ulf Hansson
>
>
> Ulf Hansson (6):
>   PM: QoS: Introduce a CPU system wakeup QoS limit
>   pmdomain: Respect the CPU system wakeup QoS limit for s2idle
>   pmdomain: Respect the CPU system wakeup QoS limit for cpuidle
>   sched: idle: Respect the CPU system wakeup QoS limit for s2idle
>   cpuidle: Respect the CPU system wakeup QoS limit for cpuidle
>   Documentation: power/cpuidle: Document the CPU system wakeup latency
>     QoS
>
>  Documentation/admin-guide/pm/cpuidle.rst |   9 ++
>  Documentation/power/pm_qos_interface.rst |   9 +-
>  drivers/cpuidle/cpuidle.c                |  12 +--
>  drivers/cpuidle/governor.c               |   4 +
>  drivers/pmdomain/core.c                  |  10 ++-
>  drivers/pmdomain/governor.c              |  33 ++++++-
>  include/linux/cpuidle.h                  |   6 +-
>  include/linux/pm_domain.h                |   1 +
>  include/linux/pm_qos.h                   |   9 ++
>  kernel/power/Kconfig                     |   4 +
>  kernel/power/qos.c                       | 106 +++++++++++++++++++++++
>  kernel/sched/idle.c                      |  12 +--
>  12 files changed, 196 insertions(+), 19 deletions(-)
>
> --

It looks good to me now.

Do you want me to pick it up or do you want to route it differently?