Documentation/power/pm_qos_interface.rst | 63 ++++++++- fs/resctrl/pseudo_lock.c | 51 +------ include/linux/pm_qos.h | 40 ++++++ include/linux/resctrl.h | 3 +- kernel/power/qos.c | 166 ++++++++++++++++++++++- 5 files changed, 268 insertions(+), 55 deletions(-)
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.
Patch1 introduces the core support for CPU affinity latency QoS in the PM
QoS framework.
Patch2 removes redundant KERN_ERR prefixes in WARN() calls in the global
CPU PM QoS interface. This change addresses issues in existing code and is
not related to the new interface introduced in this patch series.
Patch3 adds documentation for the new interface.
Patch4 fixes a minor documentation issue related to the return type of
cpu_latency_qos_request_active(). This change addresses issues in existing
doc and is not related to the new interface introduced in this patch
series.
Patch5 updates the resctrl pseudo-locking logic to use the new CPU
affinity latency QoS helpers, improving clarity and consistency. The only
functional and beneficial change is that the new interface actively wakes
up CPUs whose latency QoS values have changed, ensuring the latency limit
takes effect immediately.
Changes since v1:
- Rebased on top of current next.
- Resolve the compilation warning due to a missing static function
declaration.
- Remove the conditional compilation based on CONFIG_CPU_IDLE and make it
depend solely on CONFIG_PM.
- Add support for cpu_affinity_latency_qos_active.
- Remove cpu_affinity_latency_qos_update; will reintroduce it when needed
in the future.
- Optimize the code, for example by using cpu_affinity_latency_qos_active
inside the add/remove functions to enhance robustness.
- Refine the commit message and fix a few minor issues unrelated to this
series.
- Refactor the CPU latency PM QoS logic of resctrl pseudo_lock using the
interfaces provided by this series.
- Link to v1: https://lore.kernel.org/all/20250424095228.1112558-1-quic_zhonhan@quicinc.com/
Zhongqiu Han (5):
PM: QoS: Add support for CPU affinity latency PM QoS
PM: QOS: Remove unnecessary KERN_ERR on WARN() calls
Documentation: PM: QoS: Add CPU affinity latency PM QoS Interface
documentation
Documentation: PM: QoS: Fix return type and return value description
resctrl: Replace PM QoS logic with cpu_affinity_latency_qos_* helpers
Documentation/power/pm_qos_interface.rst | 63 ++++++++-
fs/resctrl/pseudo_lock.c | 51 +------
include/linux/pm_qos.h | 40 ++++++
include/linux/resctrl.h | 3 +-
kernel/power/qos.c | 166 ++++++++++++++++++++++-
5 files changed, 268 insertions(+), 55 deletions(-)
base-commit: 024e09e444bd2b06aee9d1f3fe7b313c7a2df1bb
--
2.43.0
On Mon, 21 Jul 2025 at 14:41, Zhongqiu Han <quic_zhonhan@quicinc.com> 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. 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. 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. [...] Kind regards Uffe
On 10/23/2025 7:03 PM, Ulf Hansson wrote: > On Mon, 21 Jul 2025 at 14:41, Zhongqiu Han <quic_zhonhan@quicinc.com> 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. > > 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. 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@quicinc.com/ — 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. 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. Please kindly let me know if you have any more question. > > [...] > > Kind regards > Uffe > -- Thx and BRs, Zhongqiu Han
On Fri, 24 Oct 2025 at 10:40, Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> wrote: > > On 10/23/2025 7:03 PM, Ulf Hansson wrote: > > On Mon, 21 Jul 2025 at 14:41, Zhongqiu Han <quic_zhonhan@quicinc.com> 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. > > > > > 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. > > > 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@quicinc.com/ > — 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. > > 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. 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. Kind regards Uffe
On 10/24/2025 6:44 PM, Ulf Hansson wrote: > On Fri, 24 Oct 2025 at 10:40, Zhongqiu Han > <zhongqiu.han@oss.qualcomm.com> wrote: >> >> On 10/23/2025 7:03 PM, Ulf Hansson wrote: >>> On Mon, 21 Jul 2025 at 14:41, Zhongqiu Han <quic_zhonhan@quicinc.com> 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@quicinc.com/ >> — 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
On 7/21/2025 8:40 PM, Zhongqiu Han 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. > > Patch1 introduces the core support for CPU affinity latency QoS in the PM > QoS framework. > > Patch2 removes redundant KERN_ERR prefixes in WARN() calls in the global > CPU PM QoS interface. This change addresses issues in existing code and is > not related to the new interface introduced in this patch series. > > Patch3 adds documentation for the new interface. > > Patch4 fixes a minor documentation issue related to the return type of > cpu_latency_qos_request_active(). This change addresses issues in existing > doc and is not related to the new interface introduced in this patch > series. > > Patch5 updates the resctrl pseudo-locking logic to use the new CPU > affinity latency QoS helpers, improving clarity and consistency. The only > functional and beneficial change is that the new interface actively wakes > up CPUs whose latency QoS values have changed, ensuring the latency limit > takes effect immediately. Hi Rafael, I hope you're doing well. I just wanted to kindly check in regarding current patch I submitted a while ago. I understand things can get busy, and there's absolutely no rush — just wanted to make sure it hasn't been missed. Thank you~ > > Changes since v1: > - Rebased on top of current next. > - Resolve the compilation warning due to a missing static function > declaration. > - Remove the conditional compilation based on CONFIG_CPU_IDLE and make it > depend solely on CONFIG_PM. > - Add support for cpu_affinity_latency_qos_active. > - Remove cpu_affinity_latency_qos_update; will reintroduce it when needed > in the future. > - Optimize the code, for example by using cpu_affinity_latency_qos_active > inside the add/remove functions to enhance robustness. > - Refine the commit message and fix a few minor issues unrelated to this > series. > - Refactor the CPU latency PM QoS logic of resctrl pseudo_lock using the > interfaces provided by this series. > - Link to v1: https://lore.kernel.org/all/20250424095228.1112558-1-quic_zhonhan@quicinc.com/ > > Zhongqiu Han (5): > PM: QoS: Add support for CPU affinity latency PM QoS > PM: QOS: Remove unnecessary KERN_ERR on WARN() calls > Documentation: PM: QoS: Add CPU affinity latency PM QoS Interface > documentation > Documentation: PM: QoS: Fix return type and return value description > resctrl: Replace PM QoS logic with cpu_affinity_latency_qos_* helpers > > Documentation/power/pm_qos_interface.rst | 63 ++++++++- > fs/resctrl/pseudo_lock.c | 51 +------ > include/linux/pm_qos.h | 40 ++++++ > include/linux/resctrl.h | 3 +- > kernel/power/qos.c | 166 ++++++++++++++++++++++- > 5 files changed, 268 insertions(+), 55 deletions(-) > > > base-commit: 024e09e444bd2b06aee9d1f3fe7b313c7a2df1bb -- Thx and BRs, Zhongqiu Han
On 7/21/25 13:40, Zhongqiu Han 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. So what's needed for the UFS use-case additionally? Would adding that here be too much?
On 7/28/2025 6:09 PM, Christian Loehle wrote: > On 7/21/25 13:40, Zhongqiu Han 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. > > So what's needed for the UFS use-case additionally? > Would adding that here be too much? > Hi Christian, Thanks for your review and discussion~ Currently my plan is only to move forward with the current patch series, which includes only the below interfaces: cpu_affinity_latency_qos_add() cpu_affinity_latency_qos_remove() cpu_affinity_latency_qos_active() For most use-cases, seems these three interfaces already sufficient. The reason I mentioned UFS is to explain why the update interface cpu_affinity_latency_qos_update() is not included at this stage. The UFS use-case is planned to use the cpu_affinity_latency_qos_update() interface in the future, which is similar to the global CPU PM QoS interface cpu_latency_qos_update_request(). -- Thx and BRs, Zhongqiu Han
On 7/28/25 11:40, Zhongqiu Han wrote: > On 7/28/2025 6:09 PM, Christian Loehle wrote: >> On 7/21/25 13:40, Zhongqiu Han 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. >> >> So what's needed for the UFS use-case additionally? >> Would adding that here be too much? >> > > Hi Christian, > Thanks for your review and discussion~ > > Currently my plan is only to move forward with the current patch series, > which includes only the below interfaces: > > cpu_affinity_latency_qos_add() > cpu_affinity_latency_qos_remove() > cpu_affinity_latency_qos_active() > > > For most use-cases, seems these three interfaces already sufficient. Probably, but IMO there's no real user of the new extended interface yet, making review harder and lacking justification. FWIW in 2014 Lina also pushed for something like $SUBJECT https://lore.kernel.org/all/1407945689-18494-5-git-send-email-lina.iyer@linaro.org/ Lina made an interface to tie the PM QoS to the relevant irq, which I think was a great idea. Maybe that series is interesting for you, too? > > > The reason I mentioned UFS is to explain why the update > interface cpu_affinity_latency_qos_update() > > is not included at this stage. The UFS use-case is planned to > use the cpu_affinity_latency_qos_update() interface in the future, which > is similar to the global CPU PM QoS interface > cpu_latency_qos_update_request().
On 8/2/2025 10:38 PM, Christian Loehle wrote: > On 7/28/25 11:40, Zhongqiu Han wrote: >> On 7/28/2025 6:09 PM, Christian Loehle wrote: >>> On 7/21/25 13:40, Zhongqiu Han 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. >>> >>> So what's needed for the UFS use-case additionally? >>> Would adding that here be too much? >>> >> >> Hi Christian, >> Thanks for your review and discussion~ >> >> Currently my plan is only to move forward with the current patch series, >> which includes only the below interfaces: >> >> cpu_affinity_latency_qos_add() >> cpu_affinity_latency_qos_remove() >> cpu_affinity_latency_qos_active() >> >> >> For most use-cases, seems these three interfaces already sufficient. > > Probably, but IMO there's no real user of the new extended interface yet, > making review harder and lacking justification. > > FWIW in 2014 Lina also pushed for something like $SUBJECT > https://lore.kernel.org/all/1407945689-18494-5-git-send-email-lina.iyer@linaro.org/ > Lina made an interface to tie the PM QoS to the relevant irq, which I think > was a great idea. Maybe that series is interesting for you, too? > Hi Christian, Thanks for the review~ Just to clarify: in patch 5/5 of the current series, I’ve included a user of the new extended interface — specifically, cpu_affinity_latency_qos_active() is used internally within the add remove interfaces. I’ve roughly reviewed this patchset you mentioned. Please correct me if my understanding is inaccurate. https://lore.kernel.org/all/1407945689-18494-5-git-send-email-lina.iyer@linaro.org/ It seems that this patch series introduces an alternative implementation and attempts to add a new type of PM QoS request — one that targets IRQs instead of CPUs. Specifically, when the IRQ affinity changes, the corresponding CPU latency constraint is updated to reflect the new CPUs that the IRQ is now affine to. And It appears that Kevin also recommended implementing this feature using the per-device API: https://lore.kernel.org/all/7h4mx9wdxe.fsf@paris.lan/ ---->>> From Kevin: I agree this is a needed feature. I didn't study it in detail yet, but after a quick glance, it looks like a good approach. ---->>> https://lore.kernel.org/all/7hd2blerqz.fsf@paris.lan/ ---->>> From Kevin: I'm curious if you looked at using the per-device QoS API for this instead of expending the system-wide API. IOW, from a per-device QoS POV, a CPU is no different than any other device, and since we already have the per-device QoS API, I wondered if that might be a better choice to implment this per-CPU feature. ---->>> May I know are you suggesting that I should evaluate whether IRQ affinity scenarios could also be valid use cases for the cpu affinity latency pm qos interface? However, there's a more fundamental assumption behind this — that a particular IRQ actually requires a CPU latency PM QoS constraint, right? >> >> >> The reason I mentioned UFS is to explain why the update >> interface cpu_affinity_latency_qos_update() >> >> is not included at this stage. The UFS use-case is planned to >> use the cpu_affinity_latency_qos_update() interface in the future, which >> is similar to the global CPU PM QoS interface >> cpu_latency_qos_update_request(). > -- Thx and BRs, Zhongqiu Han
Hi Zhongqui, My apologies for being a bit late with my comments... On 7/21/25 13:40, Zhongqiu Han 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. > > Patch1 introduces the core support for CPU affinity latency QoS in the PM > QoS framework. > > Patch2 removes redundant KERN_ERR prefixes in WARN() calls in the global > CPU PM QoS interface. This change addresses issues in existing code and is > not related to the new interface introduced in this patch series. > > Patch3 adds documentation for the new interface. > > Patch4 fixes a minor documentation issue related to the return type of > cpu_latency_qos_request_active(). This change addresses issues in existing > doc and is not related to the new interface introduced in this patch > series. > > Patch5 updates the resctrl pseudo-locking logic to use the new CPU > affinity latency QoS helpers, improving clarity and consistency. The only > functional and beneficial change is that the new interface actively wakes > up CPUs whose latency QoS values have changed, ensuring the latency limit > takes effect immediately. Could you describe a bit more the big picture of this proposed design, please? Ideally with some graph of connected frameworks & drivers and how they are going to work together. E.g.: 1. what are the other components in the kernel which would use this feature? 2. is there also a user-space interface planned for it so a HAL in the middle-ware would configure these "short-wake-up-CPU"? 3. Is it possible to view/debug from the user-space which component requested this setting for some subsets of cpus? Regards, Lukasz
On 10/23/2025 9:09 PM, Lukasz Luba wrote:
> Hi Zhongqui,
>
> My apologies for being a bit late with my comments...
>
> On 7/21/25 13:40, Zhongqiu Han 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.
>>
>> Patch1 introduces the core support for CPU affinity latency QoS in the PM
>> QoS framework.
>>
>> Patch2 removes redundant KERN_ERR prefixes in WARN() calls in the global
>> CPU PM QoS interface. This change addresses issues in existing code
>> and is
>> not related to the new interface introduced in this patch series.
>>
>> Patch3 adds documentation for the new interface.
>>
>> Patch4 fixes a minor documentation issue related to the return type of
>> cpu_latency_qos_request_active(). This change addresses issues in
>> existing
>> doc and is not related to the new interface introduced in this patch
>> series.
>>
>> Patch5 updates the resctrl pseudo-locking logic to use the new CPU
>> affinity latency QoS helpers, improving clarity and consistency. The only
>> functional and beneficial change is that the new interface actively wakes
>> up CPUs whose latency QoS values have changed, ensuring the latency limit
>> takes effect immediately.
>
> Could you describe a bit more the big picture of this proposed design,
> please?
>
> Ideally with some graph of connected frameworks & drivers and how they
> are going to work together.
Hi Lukasz,
Thank you very much for your review and discussion~
I will describe you one big picture if needed, please allow me
illustrate a simple scenario using pseudo code first:
Suppose there is a USB driver. This driver uses the kernel existing
cpu_latency_qos_* interfaces to boost its IRQ execution efficiency. Its
IRQ affinity is set to core0 and core1 according to DTS config, and the
affinity of its threaded IRQ (bottom half) is also set to CPU0 and CPU1.
=================================================================
Using the kernel existing cpu_latency_qos_* interfaces:
=================================================================
static int dwc3_sample_probe(struct platform_device *pdev)
{
cpu_latency_qos_add_request(&foo->pm_qos_req,DEFAULT_VALUE);
xxxx;
ret = devm_request_threaded_irq(xxx,xxx,foo_dwc3_pwr_irq, ....)
xxxx;
}
static irqreturn_t foo_dwc3_pwr_irq(int irq, void *dev)
{
xxxx;
cpu_latency_qos_update_request(&foo->pm_qos_req, 0);
/*.... process interrupt ....*/
cpu_latency_qos_update_request(&foo->pm_qos_req, DEFAULT_VALUE);
return IRQ_HANDLED;
}
The number of IRQ executions on each CPU:
==================================================================
IRQ HWIRQ affinity CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
320 0xb0 0x3 9782468 415472 0 0 0 0 0 0
==================================================================
==================================================================
Process: irq/320-dwc3, [affinity: 0x3] cpu:1 pid:5250 ppid:2
==================================================================
From the code, we can see that the USB module using the kernel existing
cpu_latency_qos_* interfaces sets the CPU latency to 0, which prevents
all CPUs from entering idle states—even C1. During operation, the USB
IRQs is triggered 9,782,468 times on CPU0, and each time it runs, all
CPUs are blocked from entering deeper C-states. However, only CPU0, CPU1
are actually involved in handling the IRQ and its threaded bottom half.
It will cause unnecessary power consumption on other CPUs.
(Please note, due to the simplicity of the pseudocode, I did not show
how the IRQ bottom-half thread is synchronized to restrict CPU idle
states via PM QoS. In reality, it's clear that we can also apply a CPU
latency limit to the bottom-half thread.)
If we use current patch series API cpu_affinity_latency_qos_xxx, such
as:
=================================================================
Using current patch series cpu_affinity_latency_qos_* interfaces:
=================================================================
static int dwc3_sample_probe(struct platform_device *pdev)
{
cpu_affinity_latency_qos_add(&foo->pm_qos_req,DEFAULT_VALUE, mask);
xxxx;
ret = devm_request_threaded_irq(xxx,xxx,foo_dwc3_pwr_irq, ....)
xxxx;
}
We can only constrain the CPU latency PM QoS on CPU0 and CPU1 in order
to save power.
>
> E.g.:
> 1. what are the other components in the kernel which would use this
> feature?
1.Drivers such as Audio, USB, and UFS, which currently rely on the
kernel's global CPU Latency PM QoS interface, but only require latency
constraints on a subset of CPUs, can leverage this new interface to
achieve improved power efficiency.
2.I’m considering supporting this feature in userspace.
Once implemented, userspace threads—such as mobile gaming threads that
aim to constrain CPU latency and are already bound to big cores—will be
able to use the API to help save power.
> 2. is there also a user-space interface planned for it so a HAL in
> the middle-ware would configure these "short-wake-up-CPU"?
Yes, I am considering to support userspace on patch V3.
> 3. Is it possible to view/debug from the user-space which component
> requested this setting for some subsets of cpus?
I'm uncertain whether we should provide the ability to inspect
which components are applying constraints on CPU latency. However,
what I do want to ensure is that—similar to the existing /dev
cpu_dma_latency interface in the current kernel—I can offer per-CPU
level latency value setting and querying.
>
> Regards,
> Lukasz
>
>
--
Thx and BRs,
Zhongqiu Han
On 10/24/25 09:25, Zhongqiu Han wrote:
> On 10/23/2025 9:09 PM, Lukasz Luba wrote:
>> Hi Zhongqui,
>>
>> My apologies for being a bit late with my comments...
>>
>> On 7/21/25 13:40, Zhongqiu Han 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.
>>>
>>> Patch1 introduces the core support for CPU affinity latency QoS in
>>> the PM
>>> QoS framework.
>>>
>>> Patch2 removes redundant KERN_ERR prefixes in WARN() calls in the global
>>> CPU PM QoS interface. This change addresses issues in existing code
>>> and is
>>> not related to the new interface introduced in this patch series.
>>>
>>> Patch3 adds documentation for the new interface.
>>>
>>> Patch4 fixes a minor documentation issue related to the return type of
>>> cpu_latency_qos_request_active(). This change addresses issues in
>>> existing
>>> doc and is not related to the new interface introduced in this patch
>>> series.
>>>
>>> Patch5 updates the resctrl pseudo-locking logic to use the new CPU
>>> affinity latency QoS helpers, improving clarity and consistency. The
>>> only
>>> functional and beneficial change is that the new interface actively
>>> wakes
>>> up CPUs whose latency QoS values have changed, ensuring the latency
>>> limit
>>> takes effect immediately.
>>
>> Could you describe a bit more the big picture of this proposed design,
>> please?
>>
>> Ideally with some graph of connected frameworks & drivers and how they
>> are going to work together.
>
> Hi Lukasz,
> Thank you very much for your review and discussion~
>
> I will describe you one big picture if needed, please allow me
> illustrate a simple scenario using pseudo code first:
>
> Suppose there is a USB driver. This driver uses the kernel existing
> cpu_latency_qos_* interfaces to boost its IRQ execution efficiency. Its
> IRQ affinity is set to core0 and core1 according to DTS config, and the
> affinity of its threaded IRQ (bottom half) is also set to CPU0 and CPU1.
>
>
> =================================================================
> Using the kernel existing cpu_latency_qos_* interfaces:
> =================================================================
> static int dwc3_sample_probe(struct platform_device *pdev)
> {
> cpu_latency_qos_add_request(&foo->pm_qos_req,DEFAULT_VALUE);
> xxxx;
> ret = devm_request_threaded_irq(xxx,xxx,foo_dwc3_pwr_irq, ....)
> xxxx;
> }
>
> static irqreturn_t foo_dwc3_pwr_irq(int irq, void *dev)
> {
> xxxx;
> cpu_latency_qos_update_request(&foo->pm_qos_req, 0);
>
> /*.... process interrupt ....*/
>
> cpu_latency_qos_update_request(&foo->pm_qos_req, DEFAULT_VALUE);
>
> return IRQ_HANDLED;
>
> }
>
>
> The number of IRQ executions on each CPU:
> ==================================================================
> IRQ HWIRQ affinity CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
> 320 0xb0 0x3 9782468 415472 0 0 0 0 0 0
> ==================================================================
>
> ==================================================================
> Process: irq/320-dwc3, [affinity: 0x3] cpu:1 pid:5250 ppid:2
> ==================================================================
>
>
> From the code, we can see that the USB module using the kernel existing
> cpu_latency_qos_* interfaces sets the CPU latency to 0, which prevents
> all CPUs from entering idle states—even C1. During operation, the USB
> IRQs is triggered 9,782,468 times on CPU0, and each time it runs, all
> CPUs are blocked from entering deeper C-states. However, only CPU0, CPU1
> are actually involved in handling the IRQ and its threaded bottom half.
> It will cause unnecessary power consumption on other CPUs.
> (Please note, due to the simplicity of the pseudocode, I did not show
> how the IRQ bottom-half thread is synchronized to restrict CPU idle
> states via PM QoS. In reality, it's clear that we can also apply a CPU
> latency limit to the bottom-half thread.)
>
>
> If we use current patch series API cpu_affinity_latency_qos_xxx, such
> as:
>
> =================================================================
> Using current patch series cpu_affinity_latency_qos_* interfaces:
> =================================================================
> static int dwc3_sample_probe(struct platform_device *pdev)
> {
> cpu_affinity_latency_qos_add(&foo->pm_qos_req,DEFAULT_VALUE, mask);
> xxxx;
> ret = devm_request_threaded_irq(xxx,xxx,foo_dwc3_pwr_irq, ....)
> xxxx;
> }
>
> We can only constrain the CPU latency PM QoS on CPU0 and CPU1 in order
> to save power.
Thank you for this explanation. IMO this could be part of the
documentation patch.
>
>>
>> E.g.:
>> 1. what are the other components in the kernel which would use this
>> feature?
>
> 1.Drivers such as Audio, USB, and UFS, which currently rely on the
> kernel's global CPU Latency PM QoS interface, but only require latency
> constraints on a subset of CPUs, can leverage this new interface to
> achieve improved power efficiency.
>
> 2.I’m considering supporting this feature in userspace.
> Once implemented, userspace threads—such as mobile gaming threads that
> aim to constrain CPU latency and are already bound to big cores—will be
> able to use the API to help save power.
>
>> 2. is there also a user-space interface planned for it so a HAL in
>> the middle-ware would configure these "short-wake-up-CPU"?
>
> Yes, I am considering to support userspace on patch V3.
>
>> 3. Is it possible to view/debug from the user-space which component
>> requested this setting for some subsets of cpus?
>
> I'm uncertain whether we should provide the ability to inspect
> which components are applying constraints on CPU latency. However,
> what I do want to ensure is that—similar to the existing /dev
> cpu_dma_latency interface in the current kernel—I can offer per-CPU
> level latency value setting and querying.
>
>
OK, I think this is a good approach to not tackle all in single
step, but in some phases. The user-space would need more thinking.
Regards,
Lukasz
On 10/28/2025 9:12 PM, Lukasz Luba wrote:
>
>
> On 10/24/25 09:25, Zhongqiu Han wrote:
>> On 10/23/2025 9:09 PM, Lukasz Luba wrote:
>>> Hi Zhongqui,
>>>
>>> My apologies for being a bit late with my comments...
>>>
>>> On 7/21/25 13:40, Zhongqiu Han 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.
>>>>
>>>> Patch1 introduces the core support for CPU affinity latency QoS in
>>>> the PM
>>>> QoS framework.
>>>>
>>>> Patch2 removes redundant KERN_ERR prefixes in WARN() calls in the
>>>> global
>>>> CPU PM QoS interface. This change addresses issues in existing code
>>>> and is
>>>> not related to the new interface introduced in this patch series.
>>>>
>>>> Patch3 adds documentation for the new interface.
>>>>
>>>> Patch4 fixes a minor documentation issue related to the return type of
>>>> cpu_latency_qos_request_active(). This change addresses issues in
>>>> existing
>>>> doc and is not related to the new interface introduced in this patch
>>>> series.
>>>>
>>>> Patch5 updates the resctrl pseudo-locking logic to use the new CPU
>>>> affinity latency QoS helpers, improving clarity and consistency. The
>>>> only
>>>> functional and beneficial change is that the new interface actively
>>>> wakes
>>>> up CPUs whose latency QoS values have changed, ensuring the latency
>>>> limit
>>>> takes effect immediately.
>>>
>>> Could you describe a bit more the big picture of this proposed design,
>>> please?
>>>
>>> Ideally with some graph of connected frameworks & drivers and how they
>>> are going to work together.
>>
>> Hi Lukasz,
>> Thank you very much for your review and discussion~
>>
>> I will describe you one big picture if needed, please allow me
>> illustrate a simple scenario using pseudo code first:
>>
>> Suppose there is a USB driver. This driver uses the kernel existing
>> cpu_latency_qos_* interfaces to boost its IRQ execution efficiency. Its
>> IRQ affinity is set to core0 and core1 according to DTS config, and the
>> affinity of its threaded IRQ (bottom half) is also set to CPU0 and CPU1.
>>
>>
>> =================================================================
>> Using the kernel existing cpu_latency_qos_* interfaces:
>> =================================================================
>> static int dwc3_sample_probe(struct platform_device *pdev)
>> {
>> cpu_latency_qos_add_request(&foo->pm_qos_req,DEFAULT_VALUE);
>> xxxx;
>> ret = devm_request_threaded_irq(xxx,xxx,foo_dwc3_pwr_irq, ....)
>> xxxx;
>> }
>>
>> static irqreturn_t foo_dwc3_pwr_irq(int irq, void *dev)
>> {
>> xxxx;
>> cpu_latency_qos_update_request(&foo->pm_qos_req, 0);
>>
>> /*.... process interrupt ....*/
>>
>> cpu_latency_qos_update_request(&foo->pm_qos_req, DEFAULT_VALUE);
>>
>> return IRQ_HANDLED;
>>
>> }
>>
>>
>> The number of IRQ executions on each CPU:
>> ==================================================================
>> IRQ HWIRQ affinity CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
>> 320 0xb0 0x3 9782468 415472 0 0 0 0 0 0
>> ==================================================================
>>
>> ==================================================================
>> Process: irq/320-dwc3, [affinity: 0x3] cpu:1 pid:5250 ppid:2
>> ==================================================================
>>
>>
>> From the code, we can see that the USB module using the kernel existing
>> cpu_latency_qos_* interfaces sets the CPU latency to 0, which prevents
>> all CPUs from entering idle states—even C1. During operation, the USB
>> IRQs is triggered 9,782,468 times on CPU0, and each time it runs, all
>> CPUs are blocked from entering deeper C-states. However, only CPU0, CPU1
>> are actually involved in handling the IRQ and its threaded bottom half.
>> It will cause unnecessary power consumption on other CPUs.
>> (Please note, due to the simplicity of the pseudocode, I did not show
>> how the IRQ bottom-half thread is synchronized to restrict CPU idle
>> states via PM QoS. In reality, it's clear that we can also apply a CPU
>> latency limit to the bottom-half thread.)
>>
>>
>> If we use current patch series API cpu_affinity_latency_qos_xxx, such
>> as:
>>
>> =================================================================
>> Using current patch series cpu_affinity_latency_qos_* interfaces:
>> =================================================================
>> static int dwc3_sample_probe(struct platform_device *pdev)
>> {
>> cpu_affinity_latency_qos_add(&foo->pm_qos_req,DEFAULT_VALUE, mask);
>> xxxx;
>> ret = devm_request_threaded_irq(xxx,xxx,foo_dwc3_pwr_irq, ....)
>> xxxx;
>> }
>>
>> We can only constrain the CPU latency PM QoS on CPU0 and CPU1 in order
>> to save power.
>
> Thank you for this explanation. IMO this could be part of the
> documentation patch.
>
Hi Lukasz,
Thanks for the nice suggestion. Yes, having documentation with examples
would definitely make it more convenient for users.
>>
>>>
>>> E.g.:
>>> 1. what are the other components in the kernel which would use this
>>> feature?
>>
>> 1.Drivers such as Audio, USB, and UFS, which currently rely on the
>> kernel's global CPU Latency PM QoS interface, but only require latency
>> constraints on a subset of CPUs, can leverage this new interface to
>> achieve improved power efficiency.
>>
>> 2.I’m considering supporting this feature in userspace.
>> Once implemented, userspace threads—such as mobile gaming threads that
>> aim to constrain CPU latency and are already bound to big cores—will be
>> able to use the API to help save power.
>>
>>> 2. is there also a user-space interface planned for it so a HAL in
>>> the middle-ware would configure these "short-wake-up-CPU"?
>>
>> Yes, I am considering to support userspace on patch V3.
>>
>>> 3. Is it possible to view/debug from the user-space which component
>>> requested this setting for some subsets of cpus?
>>
>> I'm uncertain whether we should provide the ability to inspect
>> which components are applying constraints on CPU latency. However,
>> what I do want to ensure is that—similar to the existing /dev
>> cpu_dma_latency interface in the current kernel—I can offer per-CPU
>> level latency value setting and querying.
>>
>>
>
> OK, I think this is a good approach to not tackle all in single
> step, but in some phases. The user-space would need more thinking.
>
Acked, I will focus on the kernel space side first.
> Regards,
> Lukasz
--
Thx and BRs,
Zhongqiu Han
© 2016 - 2026 Red Hat, Inc.