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: <CAPDyKFprP1d-9Ojwz7QaVBbdFumPmRoVnifrP8v+eL6FHR3Unw@mail.gmail.com>
Date: Thu, 23 Oct 2025 13:03:20 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Zhongqiu Han <quic_zhonhan@...cinc.com>
Cc: 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
Subject: Re: [PATCH v2 0/5] PM QoS: Add CPU affinity latency QoS support and
 resctrl integration

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.

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.

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.

[...]

Kind regards
Uffe