I'm in favor of this (consider it a bugfix really), and think we should defer on trying to be clever (e.g. introduce some minimum sleep time like #19598 does.) The entire thing here is probably a holdover from using poll(), which only has millisecond precision, and someone might've gone "oh but I need this 0.5ms timer to work, I'll just busy loop".

For reference, context switches on modern OSes take single digit µs times, cf. https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/ (might be even less 7 years later). And note that when calling ppoll(), we're done doing things and likely won't have anything valuable in CPU caches. With that in mind, it feels entirely reasonable to pass small timeouts into ppoll(). The kernel people aren't stupid either, there's probably some minimum timeout below which it will just spin in the kernel (or rather, "short-sleep" the CPU core, rather than spin) and not task switch.

While there certainly could be gains had from doing some accumulation/batching of timers, there can also be unforeseen effects, even to the network level in terms of microbursts. (Unlikely, but possible.) Without data showing us any benefit of that, let's just stick to the simple.

I guess I don't think the FRR issue is with context-switching, or cpu caches, or sub-microsecond packet-processing in a dataplane somewhere. I think we have two use-cases: control-plane timers, and BFD.

the control-plane protocols (and some of our own internal components/IPCS/etc) use timers. those timers are usually at second scale - there's not value at all in nanosecond precision for those timers.

BFD is sort of a special case, because we seem to be under some pressure to support quite tight timers for BFD in user-space, and at some scale in terms of number of peers/sessions. Those timers are at tens-of-milliseconds scale or thereabouts. Even there, we have only seen that those kinds of timers hit a ceiling when the system is busy.

But what we've been doing is not "simple": the library code does extra work to sort the timer list at sub-millisecond precision, and we try very hard to distinguish between multiple timers that are scheduled microseconds apart. As Donald has shown, that only wastes cpu time without benefitting network stability at all. so my preference would be to be "simple": we make it clear that our apis support millisecond resolution, for example, and we plumb that through the various layers so we aren't doing extra work to support a precision that we can't hope to reliably achieve.

For reference, context switches on modern OSes take single digit µs times, cf. https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/ (might be even less 7 years later). [...] And note that when calling ppoll(), we're done doing things and likely won't have anything valuable in CPU caches.

While there certainly could be gains had from doing some accumulation/batching of timers, there can also be unforeseen effects, even to the network level in terms of microbursts. (Unlikely, but possible.) Without data showing us any benefit of that, let's just stick to the simple.

As discussed in the community meeting , I have not removed the selectpoll_timeout code. I have just recalculated the correct tsp for ppoll inside "#if defined HAVE_PPOLL". poll() continues to use the old timeout calculation.