Message-ID: <CAPDyKFqVKWCApVFjYpgXa2x3N9F7O1bGBBPz0JfNrWBYtg=M0A@mail.gmail.com>
Date: Fri, 24 Oct 2025 12:44:00 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Zhongqiu Han <zhongqiu.han@....qualcomm.com>
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
Subject: Re: [PATCH v2 0/5] PM QoS: Add CPU affinity latency QoS support and
 resctrl integration

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.

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

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

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

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.

Kind regards
Uffe

Powered by blists - more mailing lists