Messages in this thread | | | Date | Thu, 14 Sep 2023 11:29:40 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 3/5] tick/nohz: Don't shutdown the lowres tick from itself |
| |
On Wed, Sep 13, 2023 at 09:17:21PM -0400, Joel Fernandes wrote: > On Tue, Sep 12, 2023 at 6:44 AM Frederic Weisbecker <frederic@kernel.org> wrote: > > > > In lowres dynticks mode, just like in highres dynticks mode, when there > > is no tick to program in the future, the tick eventually gets > > deactivated either: > > > > * From the idle loop if in idle mode. > > * From the IRQ exit if in full dynticks mode. > > > > Therefore there is no need to deactivate it from the tick itself. This > > just just brings more overhead in the idle tick path for no reason. > > > > Fixes: 62c1256d5447 ("timers/nohz: Switch to ONESHOT_STOPPED in the low-res handler when the tick is stopped") > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org> > > If on some weird hardware, say ts->next_tick = KTIME_MAX but a > spurious timer interrupt went off and tick_nohz_handler() did get > called (yeah weird hypothetical situation), then in > tick_nohz_stop_tick() we might early return from: > > /* Skip reprogram of event if its not changed */ > if (ts->tick_stopped && (expires == ts->next_tick)) > > without no "eventual" reprogramming. > > Maybe we should also reprogram with KTIME_MAX in such a situation? > Then we can get rid of it from tick_nohz_handler() for the common case > as you are doing. > > So for weird hardware, with this patch we are not doing an extra > tick_program_event(KTIME_MAX, 1); like Nick was doing. That makes me a > tad bit nervous.
So when a tick happens, ts->next_tick is reset to 0 (in tick_sched_handle()). This way if a timer interrupt fires too early, and that includes also timer interrupts when next_tick is KTIME_MAX, the timer is always reprogrammed upon the next idle loop iteration. So this shouldn't happen.
Thanks.
| |