Strange interaction with hyperthreading on Intel hybrid CPU
Michael van Acken
michael.van.acken at gmail.com
Wed Oct 11 16:54:30 UTC 2023
Given the huge difference of a factor of 2 in user time between the default
and the nosmt setup, I tried to use jfr to find some metric that differs
markedly between the two. The workload is the same: the very same task is
executed leading to the expected result. This time it's 300 back to back
compilations within a single java process. Using the threadId() of a final
virtual thread as proxy, ~570k threads seem to be utilized overall.
"jfr view hot-methods" does not show any significant difference, with the
top entry being ForkJoinPool.awaitWork() at around 5.5% in both cases.
But "jfr view latencies-by-type" shows a large difference in its Total
column for "Java Thread Park". Could this be a clue where the user time
accumulates?
### with "nosmt"
real 77.67
user 468.16
sys 13.48
jfr view latencies-by-type recording.jfr
Latencies by Type
Event Type Count Average P 99 Longest
Total
-------------------------------------- ------ ------- ------- -------
---------
Java Thread Park 18.651 36,9 ms 310 ms 2,88 s 11 m
43 s
File Write 2 11,7 ms 12,6 ms 12,6 ms
23,4 ms
### default (without "nosmt")
real 93.60
user 824.12
sys 23.08
jfr view latencies-by-type recording.jfr
Latencies by Type
Event Type Count Average P 99 Longest
Total
--------------------------------------- ------ ------- ------- -------
--------
Java Thread Park 30.263 45,7 ms 256 ms 504 ms 23 m
2 s
File Read 1 10,9 ms 10,9 ms 10,9 ms
10,9 ms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20231011/299ec7cc/attachment-0001.htm>
More information about the loom-dev
mailing list