Messages in this thread | | | From | Arjan van de Ven <> | Date | Mon, 25 Jul 2022 08:18:57 -0700 | Subject | Re: [Question] timers: trigger_dyntick_cpu() vs TIMER_DEFERRABLE |
| |
> Ah, that makes sense, thank you for highlighting the difference. The > comment *does* say "come out of *idle*", not *tickless*... > > > Now that's the theory. In practice the deferrable timers are ignored by > > both nohz-idle and nohz-full when it comes to compute the next nohz delta. > > This is a mistake that is there since the introduction of nohz-full but I've > > always been scared to break some user setup while fixing it. Anyway things > > should look like this (untested): > > > > IIUC that's making get_next_timer_interrupt() poke the deferrable base if the > CPU isn't tickless idle (IOW if it is tickless "busy" or ticking > idle). That makes sense from what you've written above, but I get your > apprehension (though AIUI "only" pinned deferrable timers should be > problematic, as the others should be migrated away). > >
taking a small step back; the idea behind deferrable timers is (mostly) that these are timers that do ongoing "maintenance" of sorts, be it counter updates or cleanup or whatever... and that if the CPU is idle, no things happen that would require such maintenance... so it's not worth waking the CPU out of idle for it... and the nature of the timer is such that delays are benign; sure the counters get sync'd maybe a bit later but it does not impact correctness.
But once "real code" is executing (we can debate if an occasional network interrupt counts as such but that's a detail) work is done that would cause the maintenance to be meaningful again, and then we do fire these timers "as usual", but ideally grouped with other timers. So frankly that doesn't mean "right the exact millisecond", after all the nature of deferrable already means that exact timing is not implied, but within reason if something else happens anyway/
| |