On Tue, Apr 05, 2022 at 09:21:16AM -0700, Alison Chaiken wrote: > On Mon, Apr 4, 2022 at 9:33 PM Frederic Weisbecker <frederic@xxxxxxxxxx> wrote: > > > > If timers are pending while the tick is reprogrammed on nohz_mode, the > > next expiry is not armed to fire now, it is delayed one jiffy forward > > instead so as not to raise an inextinguishable timer storm with such > > scenario: > > > > 1) IRQ triggers and queue a timer > > 2) ksoftirqd() is woken up > > 3) IRQ tail: timer is reprogrammed to fire now > > 4) IRQ exit > > 5) TIMER interrupt > > 6) goto 3) > > > > ...all that until we finally reach ksoftirqd. > > > > Unfortunately we are checking the wrong softirq vector bitmask since > > timersd kthread has split from ksoftirqd. Timers now have their own > > vector state field that must be checked separately. > > With kernel 5.15 and the timersd patch applied, we've observed that > x86_64 cores tend to enter deeper C-states even when there are pending > hrtimers. Presumably failure to check the right bits could also > explain that observation and, accordingly, the patch might fix it? Well, this issue rather adds unnecessary ticks. Thus I wouldn't expect deeper C-states as a consequence but who knows... Thanks.
