Message-ID: <65340b7a-b706-45ce-b0d8-29b2081f7240@quicinc.com>
Date: Mon, 4 Aug 2025 21:47:46 +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 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

Powered by blists - more mailing lists