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: <ybkahke5mxzrmt4stzpfzmspasrdsbazsttajaoo76bfkkydys@smdsjhy6is7d>
Date: Wed, 25 Jun 2025 09:39:38 -0400
From: Aaron Tomlin <atomlin@...mlin.com>
To: Mel Gorman <mgorman@...hsingularity.net>
Cc: Peter Zijlstra <peterz@...radead.org>, 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 Mon, Jun 23, 2025 at 10:49:59PM +0100, Mel Gorman wrote:
> > > 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.
> 
> Yes, we can. idle=poll can be hazardous in weird ways and it's not like
> pmqos is hard to use. For example, lets say you had a RT application with
> latency constraints running on isolated CPUs while leaving housekeeping
> CPUs alone then it's simply a case of;
> 
>         for CPU in $ISOLATED_CPUS; do
>                 SYSFS_PARAM="/sys/devices/system/cpu/cpu$CPU/power/pm_qos_resume_latency_us"
>                 if [ ! -e $SYSFS_PARAM ]; then
>                         echo "WARNING: Unable to set PM QOS max latency for CPU $CPU\n"
>                         continue
>                 fi
>                 echo $MAX_EXIT_LATENCY > $SYSFS_PARAM
>                 echo "Set PM QOS maximum resume latency on CPU $CPU to ${MAX_EXIT_LATENCY}us"
>         done
>  
> 
> In too many cases I've seen idle=poll being used when the user didn't know
> PM QOS existed. The most common response I've received is that the latency
> requirements were unknown resulting in much headbanging off the table.
> Don't get me started on the hazards of limiting c-states by index without
> checking that the c-states are or splitting isolated/housekeeping across
> SMT siblings.
> 
> -- 
> Mel Gorman
> SUSE Labs

Hi Peter, Mel, 

Interesting. I was not aware of PM QOS. I will look into it, thank you!

As far as I can tell, the function cpu_idle_poll_ctrl() is used in a few
locations to ensure the running CPU does not enter a "deep" idle state i.e.,
use cpu_idle_poll() only. I do not see why cpu_idle_force_poll should
remain global. Perhaps I am missing something?


Kind regards,

-- 
Aaron Tomlin