From: Kevin Hilman <khilman@baylibre.com>
To: Ulf Hansson <ulf.hansson@linaro.org>,
"Rafael J . Wysocki" <rafael@kernel.org>
Cc: linux-pm@vger.kernel.org,
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>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/4] pmdomain: Respect the CPU system-wakeup QoS limit during s2idle
Date: Fri, 14 Nov 2025 16:23:09 -0800 [thread overview]
Message-ID: <7hh5uwkutu.fsf@baylibre.com> (raw)
In-Reply-To: <CAPDyKFr1bC1=3psegT0DM0tPQaCUm1DoOxV3xBa-gVV6oSuRVA@mail.gmail.com>
Ulf Hansson <ulf.hansson@linaro.org> writes:
> On Sat, 1 Nov 2025 at 01:11, Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> 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 am not so sure about that. The existing dev PM QoS latency is
> targeted towards runtime suspend of a device and the genpd governor
> also takes it into account for this use case.
>
> If we would start to take the same dev PM QoS latency constraint into
> account for system suspend (s2idle), it may not be what the user
> really intended. Instead, I think we should consider extending the dev
> PM QoS interface, to allow the user to set a specific latency limit
> for system wakeup. Then the genpd governor should take that into
> account for 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?
>
> It makes sense, but as stated above, I think we need a new QoS limit
> specific for system suspend.
OK, got it. I understand the need to distinguish between QoS
constraints set for runtime PM and system-wide suspend/resume.
So, instead of adding a completely separate entry for system-wide
suspend, and duplicating a bunch of code/API, what about using the QoS
flags, and adding a new flag that indicates if the resume_latency
constraint applies only to runtime PM (the default) or if it *also*
applies to system-wide suspend? (RFC patch below[1])
With this, I was able to extend your new cpu_system_power_down_ok()
function to check for any devices in the domain with a resume_latency
*and* this new flag before applying it to s2idle, and that's working
great locally.
Kevin
[1]
From d25b871c2044ee0e993fd75f5f1df36a35633d1f Mon Sep 17 00:00:00 2001
From: "Kevin Hilman (TI.com)" <khilman@baylibre.com>
Date: Thu, 13 Nov 2025 17:02:38 -0800
Subject: [RFC/PATCH] PM / QoS: add flag to indicate latency applies
system-wide
Add new PM_QOS_FLAG_LATENCY_SYS flag to indicate that the
resume_latency QoS constraint applies not just to runtime PM
transitions but also to system-wide suspend/s2idle.
Signed-off-by: Kevin Hilman (TI.com) <khilman@baylibre.com>
---
drivers/base/power/sysfs.c | 27 +++++++++++++++++++++++++++
include/linux/pm_qos.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
index 13b31a3adc77..9136c13c17e4 100644
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -316,6 +316,32 @@ static ssize_t pm_qos_no_power_off_store(struct device *dev,
static DEVICE_ATTR_RW(pm_qos_no_power_off);
+static ssize_t pm_qos_latency_sys_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sysfs_emit(buf, "%d\n", !!(dev_pm_qos_requested_flags(dev)
+ & PM_QOS_FLAG_LATENCY_SYS));
+}
+
+static ssize_t pm_qos_latency_sys_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t n)
+{
+ int ret;
+
+ if (kstrtoint(buf, 0, &ret))
+ return -EINVAL;
+
+ if (ret != 0 && ret != 1)
+ return -EINVAL;
+
+ ret = dev_pm_qos_update_flags(dev, PM_QOS_FLAG_LATENCY_SYS, ret);
+ return ret < 0 ? ret : n;
+}
+
+static DEVICE_ATTR_RW(pm_qos_latency_sys);
+
#ifdef CONFIG_PM_SLEEP
static const char _enabled[] = "enabled";
static const char _disabled[] = "disabled";
@@ -681,6 +707,7 @@ static const struct attribute_group pm_qos_latency_tolerance_attr_group = {
static struct attribute *pm_qos_flags_attrs[] = {
&dev_attr_pm_qos_no_power_off.attr,
+ &dev_attr_pm_qos_latency_sys.attr,
NULL,
};
static const struct attribute_group pm_qos_flags_attr_group = {
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 4a69d4af3ff8..b95f52775dfb 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -37,6 +37,8 @@ enum pm_qos_flags_status {
#define PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT (-1)
#define PM_QOS_FLAG_NO_POWER_OFF (1 << 0)
+/* latency value applies to system-wide suspend/s2idle */
+#define PM_QOS_FLAG_LATENCY_SYS (2 << 0)
enum pm_qos_type {
PM_QOS_UNITIALIZED,
--
2.51.0
next prev parent reply other threads:[~2025-11-15 0:23 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
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 [this message]
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=7hh5uwkutu.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