RFR: 8307766: Linux: Provide the option to override the timer slack [v7]

Thomas Stuefe stuefe at openjdk.org
Sat Jul 1 07:36:59 UTC 2023


On Fri, 30 Jun 2023 18:13:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the description in the RFE.
>> 
>> On `c6.8xlarge`, the sleep accuracy is improved the following way:
>> 
>> 
>> % CONF=linux-x86_64-server-release make test TEST=micro:ThreadSleep.millisNanos
>> 
>> Benchmark                   (sleep)  Mode  Cnt           Score      Error  Units
>> 
>> # Default
>> ThreadSleep.millisNanos           0  avgt   15         473.727 ±    3.542  ns/op
>> ThreadSleep.millisNanos           1  avgt   15         585.868 ±    2.010  ns/op
>> 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
>> ThreadSleep.millisNanos      100000  avgt   15      158069.170 ±  329.991  ns/op
>> ThreadSleep.millisNanos     1000000  avgt   15     1059044.770 ±  370.982  ns/op
>> ThreadSleep.millisNanos    10000000  avgt   15    10060017.354 ±  399.309  ns/op
>> ThreadSleep.millisNanos   100000000  avgt   15   100062969.073 ± 2399.053  ns/op
>> ThreadSleep.millisNanos  1000000000  avgt   15  1000068474.467 ± 2669.980  ns/op
>> 
>> # -XX:TimerSlack=1
>> ThreadSleep.millisNanos           0  avgt   15         469.632 ±    1.500  ns/op
>> ThreadSleep.millisNanos           1  avgt   15         587.562 ±    8.966  ns/op
>> ThreadSleep.millisNanos          10  avgt   15         584.241 ±    1.997  ns/op
>> ThreadSleep.millisNanos         100  avgt   15        7907.160 ±   12.476  ns/op
>> ThreadSleep.millisNanos        1000  avgt   15        7913.984 ±   56.996  ns/op
>> ThreadSleep.millisNanos       10000  avgt   15       17929.107 ±  432.083  ns/op
>> ThreadSleep.millisNanos      100000  avgt   15      108154.851 ±  403.717  ns/op
>> ThreadSleep.millisNanos     1000000  avgt   15     1008854.095 ±  418.444  ns/op
>> ThreadSleep.millisNanos    10000000  avgt   15    10009902.829 ±  279.617  ns/op
>> ThreadSleep.millisNanos   100000000  avgt   15   100014000.020 ± 2143.820  ns/op
>> ThreadSleep.millisNanos  1000000000  avgt   15  1000020734.333 ± 4846.754  ns/op
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix exclusion tag

src/hotspot/os/linux/globals_linux.hpp line 90:

> 88:           "same as disabled override. See prctl(PR_SET_TIMERSLACK) for "\
> 89:           "more info.")                                                 \
> 90:                                                                         \

None of the other Linux specifc args write "(Linux specific)". I'd leave that out.

The first sentence is difficult to parse. How about "Overrides timer slack value to the given number of nanoseconds [1..n]."

Why do we need two values (-1, 0) for oob? Is the "In current Linux, 0..." info useful for anything? I'd just use "0" as "default".

src/hotspot/os/linux/os_linux.cpp line 1000:

> 998:       }
> 999:     }
> 1000: 

Maybe also in create_attached_thread? And then it would make sense to factor this out into a small static helper.

src/hotspot/os/linux/os_linux.cpp line 4722:

> 4720:     }
> 4721:   }
> 4722: 

Is this enough? The API reads as if this should happen for every thread individually. 

Or do threads inherit this override from their parent threads? So you only set it once for main thread? 

But even then, you'd need to do it at least for every thread that gets attached, since their parentage is unknown.

This raises another question, if a thread is detached, should we restore the original timer slack?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13889#discussion_r1248611153
PR Review Comment: https://git.openjdk.org/jdk/pull/13889#discussion_r1248616032
PR Review Comment: https://git.openjdk.org/jdk/pull/13889#discussion_r1248619007


More information about the hotspot-runtime-dev mailing list