RFR: 8268228: TSC is not used for CPUTimeStampCounter on AMD processor [v2]
David Holmes
david.holmes at oracle.com
Tue Jun 8 13:02:35 UTC 2021
On 8/06/2021 6:24 pm, Yasumasa Suenaga wrote:
> On Fri, 4 Jun 2021 05:24:15 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:
>
>>> I ran JVM on Ryzen 3300X, and I got following `jdk.CPUTimeStampCounter` event.
>>>
>>>
>>> jdk.CPUTimeStampCounter {
>>> startTime = 10:41:14.993
>>> fastTimeEnabled = false
>>> fastTimeAutoEnabled = true
>>> osFrequency = 1000000000
>>> fastTimeFrequency = 1000000000
>>> }
>>>
>>>
>>> I confirmed 3300X supports Invariant TSC (so `fastTimeAutoEnabled` is set to `true`), however it does not seem to be used (`fastTimeEnabled` is `false`).
>>>
>>> Frequency is come from brand string from CPUID (e.g. "Intel(R) Core(TM) i3-8145U CPU @ 2.10GHz"). However AMD processor (Ryzen at least) does not have it ("AMD Ryzen 3 3300X 4-Core Processor").
>>> Fortunately rdtsc_x86.cpp can calculate the frequency like bogomips. We should fallback to it if we cannot get the frequency even if invariant TSC is supported.
>>>
>>> After this change, I got following `jdk.CPUTimeStampCounter` event. Base clock of Ryzen 3 3300X is 3.8GHz, so `fastTimeFrequency` looks good.
>>>
>>>
>>> jdk.CPUTimeStampCounter {
>>> startTime = 10:33:52.884
>>> fastTimeEnabled = true
>>> fastTimeAutoEnabled = true
>>> osFrequency = 10000000 Hz
>>> fastTimeFrequency = 3792929124 Hz
>>> }
>>>
>>>
>>> This problem is not only for JFR. I confirmed `Rdtsc` class is used in ticks.cpp , and it relates to GC code at least.
>>
>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Fix comments
>
> Ok, I will withdraw this PR, but...
>
>> 2. As Kim points out, you may be the first to actually use the bogomips
>> code with this change, which is even more scarey!
>
> No, the bogomips might be used in some systems.
>
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/rdtsc_x86.cpp#L102-L119
>
> For example, if the user runs JVM with -XX:+UseFastUnorderedTimeStamps on the machine which is not supported invariant TSC (e.g. virtualization guest), bogomips will be used. We can get following flight record on it:
Right but we don't know if anybody is actually using the flag to opt-in.
Hence I said you _might_ be the first.
David
-----
>
> jdk.CPUTimeStampCounter {
> jdk.CPUTimeStampCounter {
> startTime = 17:11:52.351
> fastTimeEnabled = true
> fastTimeAutoEnabled = false
> osFrequency = 1000000000
> fastTimeFrequency = 3792659755
> }
>
>
> But we can see following warnings, so most of user can understood it is unstable:
>
>
> The hardware does not support invariant tsc (INVTSC) register and/or cannot guarantee tsc synchronization between sockets at startup.
> Values returned via rdtsc() are not guaranteed to be accurate, esp. when comparing values from cross sockets reads. Enabling UseFastUnorderedTimeStamps on non-invariant tsc hardware should be considered experimental.
>
>
> I know it is corner case, so we can say bogomips is not widely used.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4350
>
More information about the hotspot-dev
mailing list