Linux 时钟源之 TSC：软硬件原理、使用场景、已知问题（2024）
内容提要
本文介绍了Linux时钟源TSC的软硬件知识，包括计算机组件的运行频率、时钟源、CPU频率提升、x86架构的寄存器、TSC的作用和挑战、TSC的改进、查看和监控TSC相关信息等。文章指出TSC只是一个计数器，记录CPU启动以来的cycles次数，不稳定性因素较多，不推荐用作时间度量。文章还提到了BIOS设置、BIOS SMI handler、SMI中断风暴和虚拟机TSC不稳等问题。
延伸解读
TSC 作为时钟源的适用边界
TSC 本质是记录 CPU 启动以来 cycles 的计数器，并非严格时钟。其精度高、开销低，但准确性受多核同步、超线程、频率变化、乱序执行等因素影响。内核虽将 TSC 列为高优先级时钟源，但明确不推荐作为时间度量。实际使用中，若系统对时间精度要求苛刻，应谨慎评估 TSC 的稳定性，或考虑 HPET 等替代方案，尽管后者开销更大。
constant_tsc 特性不等于运行时恒定
constant_tsc 标志仅表示 CPU 具备提供恒定速率 TSC 的能力，并不保证实际运行中 TSC 恒定。服务器厂商的 BIOS 逻辑、SMI 中断处理等可能修改 TSC 值，导致操作系统观测到的 TSC 出现波动。例如，某些 AMD EPYC 处理器虽支持 constant_tsc，但监控显示 TSC 频率仍有偏移。因此，不能仅凭 CPU 标志就认定 TSC 稳定，需结合监控数据判断。
BIOS 与 SMI 对 TSC 的干扰
TSC 寄存器可写，部分 BIOS 固件会修改 TSC 值以隐藏 SMI handler 的执行，或出于功耗控制调整 TSC 同步逻辑。这可能导致内核时序错乱，影响调度器负载均衡。若 SMI 中断频繁，大量时间消耗在中断处理却不计入 TSC，会引发系统卡顿。排查时需关注 BIOS 设置及 SMI 统计，但 AMD 平台可能无法直接查看 SMI 计数。
虚拟机环境中 TSC 的额外风险
在虚拟机中，TSC 的稳定性面临更多挑战。虚拟化层可能引入 TSC 偏移或缩放，导致 guest 内 TSC 与真实时间不同步。若宿主机 TSC 本身不稳定，或 vCPU 迁移、暂停等操作发生，guest 内计时可能严重偏差。因此，在虚拟化场景下依赖 TSC 计时需格外谨慎，建议结合其他时钟源或启用 TSC 缩放补偿机制。
Q&A
TSC在Linux系统中的作用是什么？
TSC用于记录CPU启动以来的周期数，常被用作高精度时钟，但不推荐作为时间度量。
为什么TSC不适合用作时间度量？
TSC的准确性受到多核处理器、超线程、频率变化等因素的影响，导致其不稳定。
如何查看和监控TSC相关信息？
可以使用turbostat工具查看TSC相关信息，执行命令即可获取CPU的TSC频率。
TSC的恒定速率技术有什么意义？
恒定速率TSC技术旨在提高TSC的稳定性，确保TSC以CPU的标称频率累积。
BIOS设置如何影响TSC的稳定性？
某些BIOS固件可能会修改TSC值，导致操作系统时序不同步，从而影响TSC的稳定性。
在虚拟机环境中使用TSC会遇到什么问题？
虚拟机环境中TSC的稳定性存在问题，可能导致时间计量不准确。
