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

[Aleksey Shipilev]

On Tue, 23 May 2023 02:54:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > And this is precisely (pun intended) why I'd like to have some control over the timer slack
> 
> I'm still not really understanding what this timer slack actually means in practice and how it relates to the sleep benchmark.

Perhaps this LWN article would help: https://lwn.net/Articles/369549/


Arjan van de Ven has proposed an enhancement to the timer API - called 
[timer slack](http://lwn.net/Articles/369361/) - which should make it easier to coalesce
timer events. In essence, it adds a certain amount of fuzziness to timer 
expiration times, giving the kernel some flexibility in how the timers are scheduled.
That fuzziness is set with:

    void set_timer_slack(struct timer_list *timer, int slack_hz);

In essence, this call says that any timeout scheduled with the given timer can be
delayed by up to slack_hz jiffies. By default, the slack is set to 0.4% of the total 
timeout period - a very conservative value. When the timer is queued, the actual 
expiration time is determined by means of a simple algorithm to choose a well-defined
time within the slack period.


Larger timer slack => coarser timer expiration window => more opportunities to merge timers / keep CPUs at low power state => less accuracy / more efficiency. 

Timer slack affects `Thread.sleep`, because we effectively use hi-res timers that are subject to timer slack to perform the sleep.

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

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