From: Russell Haley <yumpusamongus@gmail.com>
To: "Ionut Nechita (Sunlight Linux)" <sunlightlinux@gmail.com>,
christian.loehle@arm.com
Cc: daniel.lezcano@linaro.org, ionut_n2001@yahoo.com,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
rafael@kernel.org
Subject: Re: [PATCH v2 0/1] cpuidle: menu: Fix high wakeup latency on modern platforms
Date: Mon, 9 Feb 2026 17:24:13 -0600 [thread overview]
Message-ID: <83e65606-cbbf-421a-9de6-9e39a7d872dd@gmail.com> (raw)
In-Reply-To: <20260126201943.11505-2-sunlightlinux@gmail.com>
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
prev parent reply other threads:[~2026-02-09 23:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 8:09 Ionut Nechita (Sunlight Linux)
2026-01-22 8:09 ` [PATCH v2 1/1] cpuidle: menu: Use min() to prevent deep C-states when tick is stopped Ionut Nechita (Sunlight Linux)
2026-01-22 11:19 ` David Laight
2026-01-22 8:49 ` [PATCH v2 0/1] cpuidle: menu: Fix high wakeup latency on modern platforms Christian Loehle
2026-01-26 20:19 ` Ionut Nechita (Sunlight Linux)
2026-02-09 23:24 ` Russell Haley [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83e65606-cbbf-421a-9de6-9e39a7d872dd@gmail.com \
--to=yumpusamongus@gmail.com \
--cc=christian.loehle@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=ionut_n2001@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=sunlightlinux@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome