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: <f682e782-ffea-48b2-997d-ddbaf7ea8a8f@arm.com>
Date: Sat, 2 Aug 2025 15:38:54 +0100
From: Christian Loehle <christian.loehle@....com>
To: Zhongqiu Han <quic_zhonhan@...cinc.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
Subject: Re: [PATCH v2 0/5] PM QoS: Add CPU affinity latency QoS support and
 resctrl integration

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().