1

I'm doing some microbenchmarking of short code snippets using the __rdtsc intrinsic inside WSL2 on Windows 11. I'm noticing that there is a lot more variance in the results than I'm used to from working on machines that are running Linux on bare metal. If I use clock_gettime with CLOCK_MONOTONIC_RAW instead my results across runs are much more consistent. From prior experience this made me suspect that the TSC might not be reliable, so I ran dmesg and found this:

tsc: Marking TSC unstable due to running on Hyper-V

Which is surprising because that directly contradicts the documentation here:

Hyper-V initialization code in Linux reads this MSR to get the frequency, so it skips TSC calibration and sets tsc_reliable.

Any ideas why this is happening? Is there a way for me to use plain __rdtsc? I notice my /proc/cpuinfo does have constant_tsc but not nonstop_tsc, but since my CPU is new enough to be running Windows 11 I assume this is an artifact of running in WSL2.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Joseph Garvin
  • 20,727
  • 18
  • 94
  • 165
  • 1
    `clock_gettime` uses scale factors for RDTSC to compute an offset since the last timer tick (the thing you could read with `CLOCK_MONOTONIC_COARSE`). That requires `constant_tsc` but not `nonstop_tsc`, at least on real hardware where the kernel can be sure when the underlying CPU was asleep. (I guess it uses a different mechanism to update the coarse clock on wakeups.) IDK about the situation on Windows / Hyper-V. You might single-step into the VDSO stub in a call to `clock_gettime` in a running process and see if it uses RDTSC at all. – Peter Cordes Apr 24 '23 at 07:28
  • @PeterCordes I think you edited the title wrong? I state in the last paragraph that `/proc/cpuinfo` does have `constant_tsc`. – Joseph Garvin Apr 24 '23 at 17:17
  • Oops, yeah, I got it backwards. – Peter Cordes Apr 24 '23 at 21:08

0 Answers0