From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Linux PM <linux-pm@vger.kernel.org>
Cc: Frederic Weisbecker <frederic@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Christian Loehle <christian.loehle@arm.com>
Subject: [PATCH v1 3/3] cpuidle: governors: menu: Special-case nohz_full CPUs
Date: Wed, 13 Aug 2025 12:29:51 +0200 [thread overview]
Message-ID: <2244365.irdbgypaU6@rafael.j.wysocki> (raw)
In-Reply-To: <2804546.mvXUDI8C0e@rafael.j.wysocki>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When the menu governor runs on a nohz_full CPU and there are no user
space timers in the workload on that CPU, it ends up selecting idle
states with target residency values above TICK_NSEC all the time due to
a tick_nohz_tick_stopped() check designed for a different use case.
Namely, on nohz_full CPUs the fact that the tick has been stopped does
not actually mean anything in particular, whereas in the other case it
indicates that previously the CPU was expected to be idle sufficiently
long for the tick to be stopped, so it is not unreasonable to expect
it to be idle beyond the tick period length again.
In some cases, this behavior causes latency in the workload to grow
undesirably. It may also cause the workload to consume more energy
than necessary if the CPU does not spend enough time in the selected
deep idle states.
Address this by amending the tick_nohz_tick_stopped() check in question
with a tick_nohz_full_cpu() one to avoid using the time till the next
timer event as the predicted_ns value all the time on nohz_full CPUs.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/cpuidle/governors/menu.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -293,8 +293,18 @@
* in a shallow idle state for a long time as a result of it. In that
* case, say we might mispredict and use the known time till the closest
* timer event for the idle state selection.
+ *
+ * However, on nohz_full CPUs the tick does not run as a rule and the
+ * time till the closest timer event may always be effectively infinite,
+ * so using it as a replacement for the predicted idle duration would
+ * effectively always cause the prediction results to be discarded and
+ * deep idle states to be selected all the time. That might introduce
+ * unwanted latency into the workload and cause more energy than
+ * necessary to be consumed if the discarded prediction results are
+ * actually accurate, so skip nohz_full CPUs here.
*/
- if (tick_nohz_tick_stopped() && predicted_ns < TICK_NSEC)
+ if (tick_nohz_tick_stopped() && !tick_nohz_full_cpu(dev->cpu) &&
+ predicted_ns < TICK_NSEC)
predicted_ns = data->next_timer_ns;
/*
next prev parent reply other threads:[~2025-08-13 10:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 10:21 [PATCH v1 0/3] cpuidle: governors: menu: A fix, a corner case adjustment and a cleanup Rafael J. Wysocki
2025-08-13 10:25 ` [PATCH v1 1/3] cpuidle: governors: menu: Avoid selecting states with too much latency Rafael J. Wysocki
2025-08-13 19:13 ` Christian Loehle
2025-08-18 17:08 ` Rafael J. Wysocki
2025-09-11 13:37 ` Frederic Weisbecker
2025-10-23 3:05 ` Doug Smythies
2025-10-23 14:51 ` Rafael J. Wysocki
2025-10-23 16:02 ` Doug Smythies
2025-10-23 16:52 ` Rafael J. Wysocki
2025-08-13 10:26 ` [PATCH v1 2/3] cpuidle: governors: menu: Rearrange main loop in menu_select() Rafael J. Wysocki
2025-08-14 13:00 ` Christian Loehle
2025-09-11 13:37 ` Frederic Weisbecker
2025-08-13 10:29 ` Rafael J. Wysocki [this message]
2025-08-14 14:09 ` [PATCH v1 3/3] cpuidle: governors: menu: Special-case nohz_full CPUs Christian Loehle
2025-08-18 17:41 ` Rafael J. Wysocki
2025-08-19 9:10 ` Christian Loehle
2025-08-19 11:56 ` Rafael J. Wysocki
2025-09-11 14:17 ` Frederic Weisbecker
2025-09-11 17:07 ` Rafael J. Wysocki
2025-09-18 15:07 ` Frederic Weisbecker
2025-09-23 17:25 ` Rafael J. Wysocki
2026-02-08 15:59 ` Ionut Nechita (Wind River)
2026-02-20 13:02 ` Rafael J. Wysocki
2025-08-28 20:16 ` [PATCH v1] cpuidle: governors: teo: " Rafael J. Wysocki
2025-08-29 19:37 ` Rafael J. Wysocki
2025-08-31 21:30 ` Christian Loehle
2025-09-01 19:08 ` Rafael J. Wysocki
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=2244365.irdbgypaU6@rafael.j.wysocki \
--to=rafael@kernel.org \
--cc=christian.loehle@arm.com \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peterz@infradead.org \
/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