WSL2下__rdtsc结果波动大，TSC被标记不稳定的原因及解决办法

矛盾原因解析 #

Kernel.org文档描述的是标准Hyper-V虚拟化场景：这种环境下，Linux内核可以通过读取MSR寄存器直接获取TSC的固定频率，跳过校准流程并标记tsc_reliable。但WSL2是微软定制的Hyper-V轻量虚拟化实现，它的vCPU调度完全由Windows主机负责——vCPU会被频繁迁移、暂停或恢复，甚至不同核心的TSC可能出现不同步。Linux内核检测到这种非标准的Hyper-V环境后，就会输出tsc: Marking TSC unstable due to running on Hyper-V的日志，这和标准Hyper-V的处理逻辑并不冲突，只是WSL2的定制化虚拟化特性导致的差异。

__rdtsc的可用性判断 #

不建议在WSL2中使用__rdtsc进行短代码片段的微基准测试：

• 你的/proc/cpuinfo显示存在constant_tsc，说明TSC的频率是固定的，但缺少nonstop_tsc意味着CPU休眠或vCPU被调度时，TSC会停止计数；
• 结合dmesg中的TSC不稳定标记，不同核心的TSC值可能存在偏移，单次测试的结果波动会远大于裸机Linux环境，无法提供可靠的微基准数据。

替代方案验证 #

你改用clock_gettime搭配CLOCK_MONOTONIC_RAW后结果一致性提升，是因为这个时钟是系统级的单调时钟，不受系统时间调整、vCPU调度的影响，WSL2的虚拟化层会保证它的连续性和一致性，更适合做微基准测试。

内容的提问来源于stack exchange，提问作者Joseph Garvin