linux-kernel - Re: [RFC PATCH] sched: idle: Introduce CPU-specific idle=poll

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] [day] [month] [year] [list]

Message-ID: <20250623102334.GP1613200@noisy.programming.kicks-ass.net>
Date: Mon, 23 Jun 2025 12:23:34 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Aaron Tomlin <atomlin@...mlin.com>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
	dave.hansen@...ux.intel.com, x86@...nel.org, juri.lelli@...hat.com,
	vincent.guittot@...aro.org, hpa@...or.com, oleg@...hat.com,
	dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
	mgorman@...e.de, vschneid@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] sched: idle: Introduce CPU-specific idle=poll

On Sat, Jun 21, 2025 at 07:57:45PM -0400, Aaron Tomlin wrote:
> Currently, the idle=poll kernel boot parameter applies globally, forcing
> all CPUs into a shallow polling idle state to ensure ultra-low latency
> responsiveness. While this is beneficial for extremely latency-sensitive
> workloads, this global application lacks flexibility and can lead to
> significant power inefficiency. This is particularly evident in systems
> with a high CPU count, such as those utilising the
> Full Dynticks/Adaptive Tick feature (i.e., nohz_full). In such
> environments, only a subset of CPUs might genuinely require
> sub-microsecond responsiveness, while others, though active, could
> benefit from entering deeper idle states to conserve power.

Can't we already do this at runtime with pmqos? If you set your latency
demand very low, it should end up picking the poll state, no? And you
can do this per-cpu.