Messages in this thread | | | Date | Mon, 19 Jul 2021 15:54:40 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCH] timers: Fix get_next_timer_interrupt() with no timers pending |
| |
On Fri, Jul 16, 2021 at 06:38:37PM +0200, Nicolas Saenz Julienne wrote: > 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.
And also each time we iterate the idle loop. In fact __next_timer_interrupt() won't always have the same cost: the worst case is when the wheel is entirely empty after the last removal and we need to walk through all 9 levels. It's a pretty common case because it happens when the last timer expires.
And that's the only one case to measure because it's the only one covered by the counter.
> > Any thoughs? > > -- > Nicolás Sáenz >
| |