linux-kernel - Re: [PATCH v2 0/1] cpuidle: menu: Fix high wakeup latency on modern platforms

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: <83e65606-cbbf-421a-9de6-9e39a7d872dd@gmail.com>
Date: Mon, 9 Feb 2026 17:24:13 -0600
From: Russell Haley <yumpusamongus@...il.com>
To: "Ionut Nechita (Sunlight Linux)" <sunlightlinux@...il.com>,
 christian.loehle@....com
Cc: daniel.lezcano@...aro.org, ionut_n2001@...oo.com,
 linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org, rafael@...nel.org
Subject: Re: [PATCH v2 0/1] cpuidle: menu: Fix high wakeup latency on modern
 platforms

On 1/26/26 2:19 PM, Ionut Nechita (Sunlight Linux) wrote:

> I considered PM QoS and /dev/cpu_dma_latency, but they have limitations
> for this use case:
> 
> 1. Global PM QoS affects all cores, not just the isolated ones
> 2. Per-task PM QoS requires application modifications
> 3. /dev/cpu_dma_latency is system-wide, not per-core
> 
> For isolated cores with NOHZ_FULL in a realtime environment, we want
> the governor to make smarter decisions based on actual predicted idle
> time rather than relying on next_timer_ns which can be arbitrarily large
> on tickless cores.
> 

In case it helps, you can write "1" to

    /sys/devices/system/cpu/cpu*/cpuidle/state*/disable

to lock out any idle states that are too deep. That's per-core, although
it's not as "crash clean" as holding an FD for /dev/cpu_dma_latency.

- Russell Haley