Messages in this thread | | | Subject | Re: [PATCH] timers: Fix get_next_timer_interrupt() with no timers pending | From | Nicolas Saenz Julienne <> | Date | Fri, 16 Jul 2021 18:38:37 +0200 |
| |
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
| |