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] [day] [month] [year] [list]

Message-ID: <819fb853-59f7-4296-8499-715c142487f5@quicinc.com>
Date: Mon, 28 Jul 2025 18:40:22 +0800
From: Zhongqiu Han <quic_zhonhan@...cinc.com>
To: Christian Loehle <christian.loehle@....com>, <rafael@...nel.org>,
        <lenb@...nel.org>, <pavel@...nel.org>, <tony.luck@...el.com>,
        <reinette.chatre@...el.com>, <Dave.Martin@....com>,
        <james.morse@....com>, <ulf.hansson@...aro.org>,
        <amit.kucheria@...aro.org>
CC: <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Zhongqiu Han
	<quic_zhonhan@...cinc.com>
Subject: Re: [PATCH v2 0/5] PM QoS: Add CPU affinity latency QoS support and
 resctrl integration

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