From: Marco Crivellari <marco.crivellari@suse.com>
To: linux-kernel@vger.kernel.org
Cc: Frederic Weisbecker <frederic@kernel.org>,
"Paul E . McKenney" <paulmck@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Marco Crivellari <marco.crivellari@suse.com>,
Michal Hocko <mhocko@suse.com>,
Aaron Tomlin <atomlin@atomlin.com>,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
Ben Segall <bsegall@google.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Jonathan Corbet <corbet@lwn.net>,
Juri Lelli <juri.lelli@redhat.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Mel Gorman <mgorman@suse.de>,
Peter Zijlstra <peterz@infradead.org>,
Randy Dunlap <rdunlap@infradead.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@kernel.org>,
Valentin Schneider <vschneid@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>
Subject: [PATCH 0/3] Stop the idle tick on polling idle on nohz_full CPUs
Date: Fri, 6 Nov 2026 17:06:12 +0100 [thread overview]
Message-ID: <20261106160621.347228-1-marco.crivellari@suse.com> (raw)
Hi,
On nohz_full CPUs booted with idle=poll, the tick interrupts the task once
after every wakeup from idle. do_idle() restarts the tick before polling,
and on wakeup tick_nohz_idle_exit() only re-evaluates the tick if it is
stopped, so it keeps running and fires in userspace before
tick_nohz_irq_exit() stops it. Without idle=poll this doesn't happen:
since commit a5183862e76f ("tick/nohz: Conditionally restart tick on idle
exit") a nohz_full CPU leaves idle with the tick still stopped.
Marcelo Tosatti proposed stopping the tick on polling idle entry:
https://lore.kernel.org/all/aQiWfnnSzxsnwa2o@tpad/
Following Frederic's review, this series does it only on nohz_full CPUs,
and handles on the target CPU the cases where stopping the tick in polling
idle would leave a timer unprogrammed.
[ P1 ] tick/nohz: Re-evaluate the tick in polling idle and on user entry
On nohz_full CPUs the tick is re-evaluated on IRQ exit and on idle exit.
In idle, IRQ exit only does accounting and relies on the idle loop
running again, which cpu_idle_poll() doesn't do: it only returns on
TIF_NEED_RESCHED. P1 closes three gaps:
- A nohz_full kick handled in idle, e.g. after a timer is enqueued from
an interrupt on the polling CPU: nohz_full_kick_func() sets
TIF_NEED_RESCHED so that the polling loop exits and
tick_nohz_idle_exit() re-evaluates the tick.
- The expiry of a stopped tick in idle: a stopped tick is programmed for
the next timer only, and reprogramming it for the following one is
left to the idle loop. tick_nohz_handler() sets TIF_NEED_RESCHED so
that timers already queued are programmed in turn.
- The return to userspace: if the tick was left running in the kernel,
e.g. because a tick dependency was cleared (which doesn't kick the
CPU), stop it from context tracking instead of letting it fire once
in userspace.
The first two only matter once P2 stops the tick in polling idle, so P1
must come first.
[ P2 ] sched/idle: Stop the tick on polling idle on nohz_full CPUs
With idle=poll, nohz_full CPUs stop the tick on idle entry instead of
restarting it. Housekeeping CPUs keep restarting it, and the
tick_check_broadcast_expired() polling case is unchanged.
[ P3 ] Documentation: no_hz: Add tick stop in polling idle
Document the above in the idle=poll item of "Known Issues".
With big effort on the Claude side, I made a test suite to help testing
the work:
https://github.com/DispatchCode/nohz-full-polling-idle-tick-test-suite
The following is a short summary of the results.
On x86_64 guest, HZ=1000, nohz_full=2-3 idle=poll), a task alternating
100us sleeps with 10ms of userspace work, 200 times:
- ticks in userspace: 200/200 -> 0/200
- ticks while polling: 35 -> 0
- housekeeping CPUs: unchanged (tick runs while polling)
- P2 without the kick change: 15 of 20 timers enqueued from an
interrupt on the polling CPU lost
- P2 without the stopped tick fix: the second of two queued timers up
to 1.9s late
Tick dependencies (POSIX CPU timers, two tasks on the CPU) and CPU hotplug
were also checked.
Thanks,
Marco Crivellari (3):
tick/nohz: Re-evaluate the tick on polling idle and on user entry
sched/idle: Stop the tick on polling idle on nohz_full CPUs
Documentation: no_hz: Add tick stop in polling idle
Documentation/timers/no_hz.rst | 3 ++
include/linux/tick.h | 10 ++++++
kernel/context_tracking.c | 9 ++++++
kernel/sched/idle.c | 5 ++-
kernel/time/tick-sched.c | 59 +++++++++++++++++++++++++++++++++-
5 files changed, 84 insertions(+), 2 deletions(-)
--
2.56.0
next reply other threads:[~2026-11-06 16:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 16:06 Marco Crivellari [this message]
2026-11-06 16:06 ` [PATCH 1/3] tick/nohz: Re-evaluate the tick on polling idle and on user entry Marco Crivellari
2026-11-06 16:06 ` [PATCH 2/3] sched/idle: Stop the tick on polling idle on nohz_full CPUs Marco Crivellari
2026-11-06 16:06 ` [PATCH 3/3] Documentation: no_hz: Add tick stop in polling idle Marco Crivellari
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=20261106160621.347228-1-marco.crivellari@suse.com \
--to=marco.crivellari@suse.com \
--cc=anna-maria@linutronix.de \
--cc=atomlin@atomlin.com \
--cc=bsegall@google.com \
--cc=corbet@lwn.net \
--cc=dietmar.eggemann@arm.com \
--cc=frederic@kernel.org \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=skhan@linuxfoundation.org \
--cc=tglx@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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
all inboxes | Powered by JetHome®