Re: [PATCH v2 0/5] PM QoS: Add CPU affinity latency QoS support and resctrl integration
From: Zhongqiu Han
Date: Mon Oct 27 2025 - 08:47:31 EST
On 10/24/2025 6:44 PM, Ulf Hansson wrote:
On Fri, 24 Oct 2025 at 10:40, Zhongqiu Han
<zhongqiu.han@xxxxxxxxxxxxxxxx> wrote:
On 10/23/2025 7:03 PM, Ulf Hansson wrote:
On Mon, 21 Jul 2025 at 14:41, Zhongqiu Han <quic_zhonhan@xxxxxxxxxxx> wrote:
Hi all,
This patch series introduces support for CPU affinity-based latency
constraints in the PM QoS framework. The motivation is to allow
finer-grained power management by enabling latency QoS requests to target
specific CPUs, rather than applying system-wide constraints.
The current PM QoS framework supports global and per-device CPU latency
constraints. However, in many real-world scenarios, such as IRQ affinity
or CPU-bound kernel threads, only a subset of CPUs are
performance-critical. Applying global constraints in such cases
unnecessarily prevents other CPUs from entering deeper C-states, leading
to increased power consumption.
This series addresses that limitation by introducing a new interface that
allows latency constraints to be applied to a CPU mask. This is
particularly useful on heterogeneous platforms (e.g., big.LITTLE) and
embedded systems where power efficiency is critical for example:
driver A rt kthread B module C
CPU IDs (mask): 0-3 2-5 6-7
target latency(us): 20 30 100
| | |
v v v
+---------------------------------+
| PM QoS Framework |
+---------------------------------+
| | |
v v v
CPU IDs (mask): 0-3 2-3,4-5 6-7
runtime latency(us): 20 20, 30 100
The current implementation includes only cpu_affinity_latency_qos_add()
and cpu_affinity_latency_qos_remove() interfaces. An update interface is
planned for future submission, along with PM QoS optimizations in the UFS
subsystem.
My apologies for the very late reply.
Hi Uffe,
I truly appreciate your review and discussion~
To fully understand how this new QoS interface is going to be used, I
really think we need to include a user of it, as part of the $subject
series.
Yes, Patch 5/5 using the cpu_affinity_latency_qos_* helper functions to
replace the logic in pseudo-locking that uses dev_pm_qos_request to
restrict CPU latency for known CPUs (via a mask). Actually, I'm also
looking for more users — for example, we plan to use these interfaces
in our UFS module in the future to implement optimizations. And I also
plan to support it in userspace on patch V3.
Right, in regards to the resctrl/pseudo-locking user of this new QoS
interface, this whole series looks more like a refactoring to me.
My point is, for this reason alone, I don't think it makes sense to
introduce this new QoS interface. We need another user too, like UFS,
to understand how this would work in real practice and to allow it to
be merged.
Thanks Uffe, I will continue to collaborate with our UFS team, or find
other users as examples.
Besides the comments from Rafael and Christian, I also wonder how the
user of the interface should know what CPU-mask it should use? For
example, how does it know the CPU-mask for the big-cores and for the
little-cores? In particular as I assume the user isn't a platform
specific driver, but rather a generic driver that should work across
various platforms.
This patch introduces cpu_affinity_latency_qos_* helper functions as an
extension to the kernel existing cpu_latency_qos_* interfaces. These new
helpers enable users to apply latency constraints to specific CPUs via a
mask, allowing for more precise power management when the target CPUs
are known in advance.
If the user is a generic driver, there are two options:
1.One is to use the existing cpu_latency_qos_* interfaces to directly
restrict all CPUs from entering idle, since the driver may not know
which specific CPUs need to be constrained.
Right, which is how UFS does it currently.
Yes, exactly.
2.However, for generic drivers with specific workload characteristics
such as the ufshcd driver in this patch:
https://lore.kernel.org/all/20231213124353.16407-1
-quic_mnaresh@xxxxxxxxxxx/
— if a user knows exactly which CPUs should be restricted, they can
provide a custom mask via a hook function and use the extended API
accordingly. The default return value of the hook is the system-wide
possible CPUs, so it won't affect other users.
Sorry, but I couldn't find in the above series how exactly UFS knows
about which CPUs it should constrain.
Again, please provide a user (UFS for example) of the new QoS
interface as a part of the series.
Sure, will do that.
In summary, this patch is mainly intended for users who know which CPUs
they want to restrict. For users who don't, the extended API can still
be used by passing a system-wide CPU mask, or they can simply use the
existing cpu_latency_qos_* interfaces.
I understand, thanks for clarifying.
Thanks for the review and discussion~
This all said, I have to admit that it kind of starts to worry me when
I see the number of different users of cpu_latency_qos interface
increasing in the kernel. To me, it feels like these are just papering
of another real problem that ideally should be solved in a more
central place, for everyone. But hey, that's another separate problem
that we can discuss at some other point.
Yes, We should strive to avoid unnecessary overhead. I will also look
into modules where it's clear which CPUs' PM QoS constraints are being
applied, as those might be optimized. I will also do an investigation.
Kind regards
Uffe
--
Thx and BRs,
Zhongqiu Han