Re: [PATCH] timers: Fix get_next_timer_interrupt() with no timers pending

[Nicolas Saenz Julienne <nsaenzju@redhat.com>]

On Sat, 2021-07-10 at 02:52 +0200, Frederic Weisbecker wrote:
> I guess later we can turn this .timers_pending into
> .timers_count and that would spare us the costly call to
> __next_timer_interrupt() up to the last level after the last
> timer is dequeued.

I've been looking into this. AFAIU there is no limit to the number of timers
one might enqueue, so there is no fool proof way of selecting .timers_count's
size. That said, 'struct timer_list' size is 40 bytes (as per pahole), so in
order to overflow an u32 .timers_count you'd need to allocate ~160GB in 'struct
timer_list' which I think is safe to assume will never happen.

Also, I measured the costy call to __next_timer_interrupt() it's slightly less
than 1us on my test machine. Not a that big in the grand scheme of things, but
it's in the irq exit code path, so I think it's worth the extra complexity in
the timer code.

Any thoughs?

-- 
Nicolás Sáenz