当前系统正在使用的时钟源可通过cat /sys/devices/system/clocksource/clocksource0/current_clocksource查看，常见值有tsc、hpet、acpi_pm等；tsc精度最高但需CPU支持constant_tsc和nonstop_tsc特性。
怎么确认当前系统正在用哪个时钟源
Linux 启动后会自动选择一个可用的硬件时钟源（如 tsc、hpet、acpi_pm、clocksource=xxx），但不一定是最优的。运行以下命令可实时查看：
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
同时检查可用选项：
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
常见现象：虚拟机里常看到 jiffies（低精度 fallback）或 hyperv_clocksource；物理机上若 tsc 不稳定（比如 CPU 频率动态缩放未禁用），系统可能退回到 acpi_pm，导致 clock_gettime(CLOCK_MONOTONIC) 调用变慢或抖动增大。
如何在启动时强制指定 clocksource
最可靠的方式是通过内核启动参数固定时钟源，避免运行时被自动切换。编辑 /etc/default/grub，修改 GRUB_CMDLINE_LINUX 行，追加 clocksource=xxx：
-
clocksource=tsc：x86-64 物理机首选，要求 CPU 支持恒定 TSC（constant_tscflag），且 BIOS 中关闭 C-state 深度节能（否则 TSC 可能停摆） -
clocksource=hpet：老式主板兼容性好，但精度和性能不如 TSC，且部分平台 HPET 本身有硬件 bug -
clocksource=acpi_pm：通用但慢，仅作兜底
改完后执行 sudo update-grub && sudo reboot。验证是否生效：重启后再次检查 /sys/.../current_clocksource，必须与参数一致——注意，运行时写入 echo tsc > /sys/.../current_clocksource 可能失败（返回 Invalid argument），因为内核已锁定或该源不可用。
为什么 tsc 有时不被启用，即使 CPU 支持
内核启动时会对 TSC 做多项检测，任一失败即弃用：tsc 不会被选为默认源，即使你没显式禁用。典型原因包括：
- CPU 不支持
constant_tsc（老 Atom 或某些超线程异常的 Xeon） - BIOS 开启了 Intel SpeedStep / AMD Cool'n'Quiet，导致 TSC 频率随倍频变化（此时需加
nohz_full或禁用节能策略） - 启用了 KVM 虚拟化但宿主机未透传 TSC（
kvm_intel.tsc_scaling=1未设或invtsc未启用） - 内核命令行含
notsc或clocksource=jiffies等冲突参数
排查方法：启动后运行 dmesg | grep -i tsc，关注类似 TSC deadline timer available 或 Failed to verify TSC synchronization 的日志。
clocksource 切换对应用的实际影响
多数用户感知不到差异，但在高精度计时场景下区别明显：
- 延迟敏感服务（如 eBPF tracepoint 时间戳、DPDK 用户态轮询、实时音视频同步）依赖
CLOCK_MONOTONIC稳定性；tsc抖动通常 acpi_pm 可达微秒级偏差 - 容器中若使用
hostnetwork+hostpid，宿主机 clocksource 直接影响容器内gettimeofday()性能（尤其 glibc 2.34+ 默认走 VDSO 路径，依赖底层 clocksource 实现） - 启用
NO_HZ_FULL内核配置时，tsc是唯一支持 full dynticks 的源，否则 tick 无法完全停掉
真正容易被忽略的是：即使你设了 clocksource=tsc，如果内核版本 tsc-verify 补丁，在多 socket NUMA 系统上仍可能因跨 socket TSC 不同步而 fallback —— 此时需配合 rdtscp 检查或 BIOS 设置 “TSC Sync” 选项。
