PM: QoS: Introduce boot parameter pm_qos_resume_latency_us

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

---
Changes in v3 [1]:
- Moved pm_qos_get_boot_cpu_latency_limit() declaration out of the CONFIG_PM #ifdef block, as qos.c is compiled regardless

Changes in v2 [2]:
- Add pr_fmt() to standardise log prefixes (Zhongqiu Han)
- Drop <asm/setup.h> by duplicating the command line with kstrdup() (Zhongqiu Han)
- Fix init_pm_qos_resume_latency_us_setup() error path to return -ENOMEM (Zhongqiu Han)

Changes since v1 [3]:
- 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/[email protected]/
[2]: https://lore.kernel.org/lkml/[email protected]/
[3]: https://lore.kernel.org/lkml/[email protected]/

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

index 55ffc0f8858a..ef1f70de7d47 100644
@@ -2251,6 +2251,29 @@ Kernel parameters
 	icn=		[HW,ISDN]
 			Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
 
+	pm_qos_resume_latency_us=	[KNL,EARLY]
+			Format: <cpu-list>:<value>[,<cpu-list>:<value>...]
+
+			Establish per-CPU resume latency constraints. These constraints
+			are applied immediately upon CPU registration and persist
+			across CPU hotplug events.
+
+			For example:
+				"pm_qos_resume_latency_us=0:0,1-15:20"
+
+			This restricts CPU 0 to a 0us resume latency (effectively
+			forcing polling) and limits CPUs 1-15 to C-states with a
+			maximum exit latency of 20us. All other CPUs remain
+			unconstrained by this parameter.
+
+			Unlike the sysfs interface, which accepts the string "n/a" to
+			remove a constraint, this boot parameter strictly requires
+			integer values. To specify a 0us latency constraint (polling),
+			the integer 0 must be used.
+
+			NOTE: The parsing logic enforces a "First Match Wins" policy.
+			If a CPU is included in multiple specified ranges, the latency
+			value from the first matching entry takes precedence.
 
 	idle=		[X86,EARLY]
 			Format: idle=poll, idle=halt, idle=nomwait

index 875abdc9942e..e522cf6e7312 100644
@@ -416,6 +416,7 @@ EXPORT_SYMBOL_GPL(cpu_subsys);
 int register_cpu(struct cpu *cpu, int num)
 {
 	int error;
+	s32 resume_latency;
 
 	cpu->node_id = cpu_to_node(num);
 	memset(&cpu->dev, 0x00, sizeof(struct device));

@@ -436,8 +437,8 @@ int register_cpu(struct cpu *cpu, int num)
 
 	per_cpu(cpu_sys_devices, num) = &cpu->dev;
 	register_cpu_under_node(num, cpu_to_node(num));
-	dev_pm_qos_expose_latency_limit(&cpu->dev,
-					PM_QOS_RESUME_LATENCY_NO_CONSTRAINT);
+	resume_latency = pm_qos_get_boot_cpu_latency_limit(num);
+	dev_pm_qos_expose_latency_limit(&cpu->dev, resume_latency);
 	set_cpu_enabled(num, true);
 
 	return 0;

index 6cea4455f867..65ce276282e8 100644
@@ -142,6 +142,7 @@ int pm_qos_update_target(struct pm_qos_constraints *c, struct plist_node *node,
 bool pm_qos_update_flags(struct pm_qos_flags *pqf,
 			 struct pm_qos_flags_request *req,
 			 enum pm_qos_req_action action, s32 val);
+s32 pm_qos_get_boot_cpu_latency_limit(unsigned int cpu);
 
 #ifdef CONFIG_CPU_IDLE
 s32 cpu_latency_qos_limit(void);

2.51.0

Hi Rafael, Danilo, Pavel, Len, Zhongqiu,

A gentle ping on this v4 series. I was hoping to see if there is any further feedback on this approach to introducing the "pm_qos_resume_latency_us=" boot parameter.

Please let me know if any further adjustments are required, or if you need me to rebase this against the latest power management tree.

Kind regards,

Aaron Tomlin