Hi Thomas,
Thomas Gleixner <t...@linutronix.de> writes:
> We now have implicit batching in the timer wheel. The slack is not longer
> used. Remove it.
> - set_timer_slack(&ev->dwork.timer, intv / 4);
> - set_timer_slack(&host->timeout_timer, HZ);
> - set_timer_slack(&di->work.timer, poll_interval * HZ / 4);
> - set_timer_slack(&ohci->io_watchdog, msecs_to_jiffies(20));
> - set_timer_slack(&xhci->comp_mode_recovery_timer,
> etc...
The current mod_timer implementation has this code:
/*
* This is a common optimization triggered by the
* networking code - if the timer is re-modified
* to be the same thing then just return:
*/
if (timer_pending(timer) && timer->expires == expires)
return 1;
In a (currently out-of-tree, but hopefully mergable soon) driver of
mine, I call mod_timer in the hot path. Every time some very frequent
event happens, I call mod_timer to move the timer back to be at
"jiffies + TIMEOUT".
>From a brief look at timer.c, it looked like __mod_timer was rather
expensive. So, as an optimization, I wanted the "timer_pending(timer)
&& timer->expires == expires" condition to be hit in most of the
cases. I accomplished this by doing:
set_timer_slack(timer, HZ / 4);
This ensured that we'd only wind up calling __mod_timer 4 times per
second, at most.
With the removal of the slack concept, I no longer can do this. I
haven't reviewed this series in depth, but I'm wondering if you'd
recommend a different optimization instead. Or, have things been
reworked so much, that calling mod_timer is now always inexpensive?
Thanks,
Jason
