[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240527155709.GA5733@redhat.com>
Date: Mon, 27 May 2024 17:57:09 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Nicholas Piggin <npiggin@...il.com>,
Peter Zijlstra <peterz@...radead.org>, Phil Auld <pauld@...hat.com>,
Chris von Recklinghausen <crecklin@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: sched/isolation: tick_take_do_timer_from_boot() calls
smp_call_function_single() with irqs disabled
On 05/26, Frederic Weisbecker wrote:
>
> Le Sun, May 26, 2024 at 09:27:58PM +0200, Oleg Nesterov a écrit :
> > > So up to this point the tick is never stopped neither on housekeeping
> > > nor on NOHZ FULL CPUs:
> > >
> > > tick_nohz_full_update_tick()
> > > if (!tick_sched_flag_test(ts, TS_FLAG_NOHZ))
> > > return;
> >
> > OK... But tick_nohz_idle_update_tick() doesn't check TS_FLAG_NOHZ and
> > the tick_nohz_full_cpu() check can't help at boot time.
>
> Yes but tick_nohz_idle_update_tick() is only called when the tick is already
> stopped. And for the tick to be already stopped, TS_FLAG_NOHZ must have been
> set.
Ah, TS_FLAG_NOHZ! Indeed, thanks.
> > And I still don't understand why we can rely on can_stop_idle_tick() even
> > in tick_nohz_idle_stop_tick().
>
> Not sure I follow you on this one...
can_stop_idle_tick() has no effect if ->timer_expires_base || tick_nohz_next_event()
but I see another email from Nicholas.
Thanks!
Oleg.
Powered by blists - more mailing lists