linux-kernel - Re: [PATCH v2 0/5] PM QoS: Add CPU affinity latency QoS support and resctrl integration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7acba50b-8c1e-4509-8100-3a65467d2d87@oss.qualcomm.com>
Date: Fri, 24 Oct 2025 16:40:13 +0800
From: Zhongqiu Han <zhongqiu.han@....qualcomm.com>
To: Ulf Hansson <ulf.hansson@...aro.org>,
        Zhongqiu Han <quic_zhonhan@...cinc.com>
Cc: rafael@...nel.org, lenb@...nel.org, pavel@...nel.org, tony.luck@...el.com,
        reinette.chatre@...el.com, Dave.Martin@....com, james.morse@....com,
        amit.kucheria@...aro.org, christian.loehle@....com,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        lukasz.luba@....com, zhongqiu.han@....qualcomm.com
Subject: Re: [PATCH v2 0/5] PM QoS: Add CPU affinity latency QoS support and
 resctrl integration

On 10/23/2025 7:03 PM, Ulf Hansson wrote:
> On Mon, 21 Jul 2025 at 14:41, Zhongqiu Han <quic_zhonhan@...cinc.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@...cinc.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