[djwatson24]

This version still has to tick, yes? The whole point of optimizing ticks-until-next-event is to support nohz tickless modes. "Optimizing for high occupancy" also means low granularity - since the more granular timeouts you need, the more likely buckets are to be empty.

[jsnell]

It doesn't need to tick in the sense of being driven by a predictable timer interrupt, since it's totally agnostic to the actual time source. The primitive for finding out when the next event expires is there for anyone wanting to operate it in a nohz-like manner. It's just a different tradeoff: make insert/delete a little faster at the expense of making ticks-until-next-event a little slower.

This is perhaps coming from a very different direction than the kernel use case. There it's totally plausible to have no events expiring for a long time (like the next second), and there is real value in going completely idle for a long period (lower power use).

But there are application areas where this just isn't the case. For example applications doing poll mode network IO can't possibly afford to go idle for a second. Even a millisecond would be stretching it. There's just no value in being slightly faster at knowing whether the next expiring timer is in 100ms or 110ms. The application will be waking up far earlier than that no matter what.

To put numbers on it: my thinking is that if a timer tick is e.g. 20us (so 50 ticks per ms) and there are no events expiring in the next 10 ticks, the system load must be so low that it might as well be completely idle.