RFR: 8307766: Linux: Provide the option to override the timer slack

[Aleksey Shipilev]

On Tue, 23 May 2023 08:52:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Perhaps this LWN article would help ...
> 
> Thanks. So are timer events only coalesced within a process, or is this system wide? I'm guessing the basic operation is that if a thread requests a "timed wait" that would require a timer event at time T1, but there already exists a timer event for time T2, (T2 > T1) then if T2-T1 < timer-slack then an event for T1 is not created and we piggy-back on the event for T2 instead. So the lower the slack the more likely we get our own timer-event and so get a resolution closer to that of the h/w, but it also means we have more timer-events to process so that could lower the resolution again.

I have not read the kernel sources for this, but my recollection is that timer lists are maintained per-CPU + there is a migration mechanics, which effectively makes timers system-wide. So timer slack allows piggy-backing on hi-res timers already pending on the system, which improves efficiency at the accuracy cost. I suspect that even if we are the only timer currently pending, the kernel would still apply the timer slack to it, hoping that some _other_ timer would be able to piggy-back on us. Which explains why a single-threaded `Thread.sleep` workload is sensitive to timer slack even on a rather quiet system.

Yes, I do wonder if we can blow out the kernel time subsystem with very low timer slack value, but that is something that needed to be checked for the concrete workload. Linux helpfully provides us the API to tune the heuristics either way, so this PR gives us the handy ability to experiment with it :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13889#issuecomment-1558877074