Message-ID: <20260128033143.3456074-1-atomlin@atomlin.com>
Date: Tue, 27 Jan 2026 22:31:42 -0500
From: Aaron Tomlin <atomlin@...mlin.com>
To: rafael@...nel.org,
	dakr@...nel.org,
	pavel@...nel.org,
	lenb@...nel.org
Cc: akpm@...ux-foundation.org,
	bp@...en8.de,
	pmladek@...e.com,
	rdunlap@...radead.org,
	feng.tang@...ux.alibaba.com,
	pawan.kumar.gupta@...ux.intel.com,
	kees@...nel.org,
	elver@...gle.com,
	arnd@...db.de,
	fvdl@...gle.com,
	lirongqing@...du.com,
	bhelgaas@...gle.com,
	neelx@...e.com,
	sean@...e.io,
	mproche@...il.com,
	chjohnst@...il.com,
	nick.lange@...il.com,
	linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org,
	linux-doc@...r.kernel.org
Subject: [v2 PATCH 0/1] PM: QoS: Introduce boot parameter pm_qos_resume_latency_us

Hi Rafael, Danilo, Pavel, Len,

Users currently lack a mechanism to define granular, per-CPU PM QoS
resume latency constraints during the early boot phase.

While the "idle=poll" boot parameter exists, it enforces a global
override, forcing all CPUs in the system to "poll". This global approach
is not suitable for asymmetric workloads where strict latency guarantees
are required only on specific critical CPUs, while housekeeping or
non-critical CPUs should be allowed to enter deeper power states to save
energy.

Additionally, the existing sysfs interface
(/sys/devices/system/cpu/cpuN/power/pm_qos_resume_latency_us) becomes
available only after userspace initialisation. This is too late to
prevent deep C-state entry during the early kernel boot phase, which may
be required for debugging early boot hangs related to C-state
transitions or for workloads requiring strict latency guarantees
immediately upon system start.

This patch introduces the pm_qos_resume_latency_us kernel boot
parameter, which allows users to specify distinct resume latency
constraints for specific CPU ranges.

	Syntax: pm_qos_resume_latency_us=range:value,range:value...

Unlike the sysfs interface which accepts the special string "n/a" to
remove a constraint, this boot parameter strictly requires integer
values. The special value "n/a" is not supported; the integer 0 must be
used to represent a 0 us latency constraint (polling).

For example:

	"pm_qos_resume_latency_us=0:0,1-15:20"

Forces CPU 0 to poll on idle; constrains CPUs 1-15 to not enter a sleep
state that takes longer than 20 us to wake up. All other CPUs will have
the default (no resume latency) applied.

Implementation Details:

	- The parameter string is captured via __setup() and parsed in
	  an early_initcall() to ensure suitable memory allocators are
	  available.

	- Constraints are stored in a read-only linked list.

	- The constraints are queried and applied in register_cpu().
	  This ensures the latency requirement is active immediately
	  upon CPU registration, effectively acting as a "birth"
	  constraint before the cpuidle governor takes over.

	- The parsing logic enforces a "First Match Wins" policy: if a
	  CPU falls into multiple specified ranges, the latency value
	  from the first matching entry is used.

	- The constraints persist across CPU hotplug events.

Please let me know your thoughts.


Changes since v1 [1]:
 - Removed boot_option_idle_override == IDLE_POLL check
 - Decoupled implementation from CONFIG_CPU_IDLE
 - Added kernel-parameters.txt documentation
 - Renamed internal setup functions for consistency

[1]: https://lore.kernel.org/lkml/20260123010024.3301276-1-atomlin@atomlin.com/

Aaron Tomlin (1):
  PM: QoS: Introduce boot parameter pm_qos_resume_latency_us

 .../admin-guide/kernel-parameters.txt         |  23 +++
 drivers/base/cpu.c                            |   5 +-
 include/linux/pm_qos.h                        |   5 +
 kernel/power/qos.c                            | 141 ++++++++++++++++++
 4 files changed, 172 insertions(+), 2 deletions(-)

-- 
2.51.0

Powered by blists - more mailing lists