[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7h1pmik3w9.fsf@baylibre.com>
Date: Fri, 31 Oct 2025 17:11:50 -0700
From: Kevin Hilman <khilman@...libre.com>
To: Ulf Hansson <ulf.hansson@...aro.org>, "Rafael J . Wysocki"
<rafael@...nel.org>, linux-pm@...r.kernel.org
Cc: Vincent Guittot <vincent.guittot@...aro.org>, Peter Zijlstra
<peterz@...radead.org>, Pavel Machek <pavel@...nel.org>, Len Brown
<len.brown@...el.com>, Daniel Lezcano <daniel.lezcano@...aro.org>,
Saravana Kannan <saravanak@...gle.com>, Maulik Shah
<quic_mkshah@...cinc.com>, Prasad Sodagudi <psodagud@...cinc.com>, Dhruva
Gole <d-gole@...com>, Ulf Hansson <ulf.hansson@...aro.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/4] pmdomain: Respect the CPU system-wakeup QoS
limit during s2idle
Ulf Hansson <ulf.hansson@...aro.org> writes:
> A CPU system-wakeup QoS limit may have been requested by user-space. To
> avoid breaking this constraint when entering a low-power state during
> s2idle through genpd, let's extend the corresponding genpd governor for
> CPUs. More precisely, during s2idle let the genpd governor select a
> suitable low-power state, by taking into account the QoS limit.
In addition to a QoS limit requested by userspace, shouldn't any
per-device QoS limits from devices in the PM domain with CPUs/clusters
also be considered?
Right now, if a device is in a PM domain that also contains CPUs, any
per-device QoS constraints for those devices should also impact the
state chosen by s2idle.
I just tried a quick hack of extending you cpu_system_power_down_ok()
function to look for any per-device QoS constraints set all devices in
the PM domain (and subdomains). It takes the min of all the per-device
QoS constratins, compares it to the one from userspace, and uses the min
of those to decide the genpd state.
That has the effect I'm after, but curious what you think about the
usecase and the idea?
Kevin
Powered by blists - more mailing lists