Message-ID: <4108296c-399c-453d-b339-7e70a423d14c@oss.qualcomm.com>
Date: Mon, 27 Oct 2025 20:38:31 +0800
From: Zhongqiu Han <zhongqiu.han@....qualcomm.com>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: 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,
        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/24/2025 6:44 PM, Ulf Hansson wrote:
> On Fri, 24 Oct 2025 at 10:40, Zhongqiu Han
> <zhongqiu.han@....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@...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.
> 
> 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@...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.
> 
> 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

Powered by blists - more mailing lists