For additional clarification, the issue is that because of the ceiling, every time we check for elapsed timeouts, the ones that are not yet elapsed are going to be checked again at best 1ms after the current check. The more often we check (ie: the more requests there is), the more likely it gets that we wake before timeout elapsed and schedule the next check 1ms away from current time.
I suspect this effect should start reversing as soon as there's more than 1000 requests/s, as the request wake ups would then act as a higher resolution timer and we would check for elapsed timers earlier, but it's not really what we want anyway.
The ceil is there since 4d1d49b78a731abe46986cfae0083154d3c578b8, and I understand it's only there to avoid getting 0 timeouts / waking up before the timeout are actually elapsed, and spinning unnecessarily. This MR solves this by using higher resolution epoll when available.
It doesn't seem to be related to timer resolution in any way, and if there's a resolution we need to implement I think it's probably something orthogonal that should be implemented in the timeout elapse time computation, not something like the current unpredictable and dynamically changing resolution.