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

[Aleksey Shipilev]

On Mon, 22 May 2023 01:36:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> ```
> ThreadSleep.millisNanos          10  avgt   15         583.475 ±    1.426  ns/op
> ThreadSleep.millisNanos         100  avgt   15       57833.073 ±  146.406  ns/op
> ThreadSleep.millisNanos        1000  avgt   15       59324.901 ±  620.924  ns/op
> ThreadSleep.millisNanos       10000  avgt   15       68071.990 ±  537.880  ns/op
> ```
> 
> Not sure what is being measured here but this looks odd. The first 10x increase to 100 results in a 100x increase. But then the next 10x is almost no difference, and the 10x after that not that much difference.

Odd, right? This is how the 50us default timer slack value introduces jitter: you can turn around fast, or you can get stalled up to the timer slack. And this is precisely (pun intended) why I'd like to have some control over the timer slack :)

> src/hotspot/os/linux/globals_linux.hpp line 82:
> 
>> 80:           "Write map file for Linux perf tool at exit")                 \
>> 81:                                                                         \
>> 82:   product(intx, TimerSlack, -1, EXPERIMENTAL,                           \
> 
> Why experimental? Is this not something that these users want to use in production?

I would say it is an option that can be used sparingly in selected production/experimental workloads. Like other low-level VM options, it stays experimental to avoid a stronger contract for supportability. I can turn that bona fide `product`, if you want.

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

PR Comment: https://git.openjdk.org/jdk/pull/13889#issuecomment-1556759244
PR Review Comment: https://git.openjdk.org/jdk/pull/13889#discussion_r1200138694