From: Frederic Weisbecker <frederic@kernel.org>
To: Marco Crivellari <marco.crivellari@suse.com>
Cc: linux-kernel@vger.kernel.org,
"Paul E . McKenney" <paulmck@kernel.org>,
Ingo Molnar <mingo@kernel.org>, Michal Hocko <mhocko@suse.com>,
Aaron Tomlin <atomlin@atomlin.com>,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
Thomas Gleixner <tglx@kernel.org>
Subject: Re: [PATCH 1/3] tick/nohz: Re-evaluate the tick on polling idle and on user entry
Date: Wed, 11 Nov 2026 10:59:29 +0100 [thread overview]
Message-ID: <avQ8gT1D6p1d2MS3@localhost.localdomain> (raw)
In-Reply-To: <CAAofZF7KAnd0xpOcgKDs6yDL9vmbON3xRAK360BBuzEpwJzu9g@mail.gmail.com>
Le Tue, Nov 10, 2026 at 06:35:49PM +0100, Marco Crivellari a écrit :
> On Tue, Nov 10, 2026 at 2:33 PM Frederic Weisbecker <frederic@kernel.org> wrote:
> > [...]
> > > With the hunk, the stopped tick firing for the first timer sets
> > > TIF_NEED_RESCHED, the polling loop exits and the tick is reprogrammed
> > > for the second timer within a few microseconds; the 10 iterations
> > > captured take 0.92s instead of ~18s. Without that hunk, the CPU stops
> > > spinning on an unrelated event.
> > >
> > > So in my understanding tick_nohz_idle_exit() program the tick only for
> > > the earliest timer; when it expire, the tick is stopped and not
> > > rearmed in tick_nohz_handler() (HRTIMER_NORESTART). Without setting
> > > NEED_RESCHED if another timer has been queued it has to wait for
> > > another event that set NEED_RESCHED.
> >
> > Hehe, you're right :)
> >
> > Let's try another strategy then. TS_FLAG_INIDLE is what tells nohz_fool whether
> > to manage the tick through the idle loop or through the IRQ exit.
> >
> > So why not calling tick_nohz_idle_enter() on each idle loop iterations? That is,
> > from cpuidle_idle_call(). And call tick_nohz_idle_exit() right before
> > cpu_idle_poll()?
>
> Aha, sounds good! :-) So INIDLE is set only when really "in idle" (eg
> no polling).
>
> > Then you can remove tick_nohz_idle_restart_tick().
>
> Should we remove only the call or also the function and its declaration?
> I'm asking because the call we're going to remove is the only one present.
You can remove also the function.
>
> > Just be careful: tick_nohz_idle_enter() and tick_nohz_idle_exit() may now be
> > unbalanced. If TS_FLAG_INIDLE is already set, tick_nohz_idle_enter() should
> > return early and tick_nohz_idle_exit() as well if !TS_FLAG_INIDLE.
> >
> > Also IRQs may now be disabled while calling tick_nohz_idle_exit(), so it should
> > use local_irq_save() and not local_irq_disable(). OTOH tick_nohz_idle_enter()
> > should always expect IRQs disabled.
> >
> > So the purpose is to move cpu_idle_poll() outside the dynticks idle logic, then
> > it's safe against nohz_full timer management, the tick keeps being stopped if
> > possible and it's only restarted for dynticks idle.
>
> Ok, I think it's clear.
>
> I've already started implementing the changes. I will send v2 with all
> the changes.
Thanks a lot!
>
> Thank you!
>
> --
>
> Marco Crivellari
>
> SUSE Labs
--
Frederic Weisbecker
SUSE Labs
next prev parent reply other threads:[~2026-11-11 9:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 16:06 [PATCH 0/3] Stop the idle tick on polling idle on nohz_full CPUs Marco Crivellari
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 22:15 ` Frederic Weisbecker
2026-11-09 17:24 ` Marco Crivellari
2026-11-10 13:33 ` Frederic Weisbecker
2026-11-10 17:35 ` Marco Crivellari
2026-11-11 9:59 ` Frederic Weisbecker [this message]
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 21:55 ` Frederic Weisbecker
2026-11-10 8:27 ` 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=avQ8gT1D6p1d2MS3@localhost.localdomain \
--to=frederic@kernel.org \
--cc=anna-maria@linutronix.de \
--cc=atomlin@atomlin.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.crivellari@suse.com \
--cc=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=paulmck@kernel.org \
--cc=tglx@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.