linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@baylibre.com>
To: Ulf Hansson <ulf.hansson@linaro.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	linux-pm@vger.kernel.org
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Pavel Machek <pavel@kernel.org>, Len Brown <len.brown@intel.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Saravana Kannan <saravanak@google.com>,
	Maulik Shah <quic_mkshah@quicinc.com>,
	Prasad Sodagudi <psodagud@quicinc.com>,
	Dhruva Gole <d-gole@ti.com>, Ulf Hansson <ulf.hansson@linaro.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/4] pmdomain: Respect the CPU system-wakeup QoS limit during s2idle
Date: Fri, 31 Oct 2025 17:11:50 -0700	[thread overview]
Message-ID: <7h1pmik3w9.fsf@baylibre.com> (raw)
In-Reply-To: <20251016151929.75863-3-ulf.hansson@linaro.org>

Ulf Hansson <ulf.hansson@linaro.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

  parent reply	other threads:[~2025-11-01  0:11 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-16 15:19 [PATCH v2 0/4] PM: QoS: Introduce a CPU system-wakeup QoS limit for s2idle Ulf Hansson
2025-10-16 15:19 ` [PATCH v2 1/4] PM: QoS: Introduce a CPU system-wakeup QoS limit Ulf Hansson
2025-10-29  8:10   ` Dhruva Gole
2025-10-29 14:28     ` Rafael J. Wysocki
2025-10-30 16:45       ` Dhruva Gole
2025-10-31 13:47         ` Ulf Hansson
2025-10-31 18:37           ` Dhruva Gole
2025-11-04 13:27             ` Ulf Hansson
2025-10-16 15:19 ` [PATCH v2 2/4] pmdomain: Respect the CPU system-wakeup QoS limit during s2idle Ulf Hansson
2025-10-30 10:44   ` Rafael J. Wysocki
2025-10-30 12:00     ` Ulf Hansson
2025-10-30 12:23       ` Rafael J. Wysocki
2025-10-30 12:32         ` Ulf Hansson
2025-10-30 14:02           ` Rafael J. Wysocki
2025-10-30 15:06             ` Ulf Hansson
2025-10-30 18:11               ` Rafael J. Wysocki
2025-10-31 10:19                 ` Ulf Hansson
2025-11-01  0:11   ` Kevin Hilman [this message]
2025-11-04 16:10     ` Ulf Hansson
2025-11-04 16:37       ` Rafael J. Wysocki
2025-11-04 16:52         ` Ulf Hansson
2025-11-04 17:53           ` Rafael J. Wysocki
2025-11-15  0:23       ` Kevin Hilman
2025-10-16 15:19 ` [PATCH v2 3/4] sched: idle: Respect the CPU system-wakeup QoS limit for s2idle Ulf Hansson
2025-10-17 10:15   ` Peter Zijlstra
2025-10-31 19:23   ` Dhruva Gole
2025-11-04 13:43     ` Ulf Hansson
2025-10-16 15:19 ` [PATCH v2 4/4] Documentation: power/cpuidle: Document the CPU system-wakeup latency QoS Ulf Hansson
2025-10-31 10:57   ` Dhruva Gole
2025-10-31 13:29     ` Ulf Hansson
2025-10-29 14:52 ` [PATCH v2 0/4] PM: QoS: Introduce a CPU system-wakeup QoS limit for s2idle Rafael J. Wysocki
2025-10-30 12:22   ` Ulf Hansson
2025-10-30 12:26     ` Rafael J. Wysocki
2025-10-30 12:29       ` Rafael J. Wysocki
2025-10-30 12:43         ` Ulf Hansson
2025-10-30 14:06           ` Rafael J. Wysocki
2025-10-30 15:12             ` Ulf Hansson
2025-10-30 16:36               ` Rafael J. Wysocki
2025-10-31 10:03                 ` Ulf Hansson

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=7h1pmik3w9.fsf@baylibre.com \
    --to=khilman@baylibre.com \
    --cc=d-gole@ti.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@kernel.org \
    --cc=peterz@infradead.org \
    --cc=psodagud@quicinc.com \
    --cc=quic_mkshah@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=saravanak@google.com \
    --cc=ulf.hansson@linaro.org \
    --cc=vincent.guittot@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).