最可靠方法是查内核编译配置CONFIG_HZ值，它代表系统定时器理论基准频率；若配置文件缺失，则用/proc/interrupts中timer中断增长速率计算实时HZ；CLK_TCK=100与内核HZ无关，/proc/timer_list不反映频率。

直接查内核编译配置的 CONFIG_HZ 值

这是最可靠、最接近“系统定时器触发频率”本意的方法。内核在编译时就固定了基础节拍率（即每秒中断次数），运行时即使启用 tickless 模式，这个值仍是底层基准。

执行命令：
grep CONFIG_HZ /boot/config-$(uname -r)

常见输出如：
CONFIG_HZ=250
CONFIG_HZ_250=y

• 若匹配到 CONFIG_HZ=xxx，该数字就是编译设定的 HZ 值（如 100、250、1000）
• 若只看到 CONFIG_HZ_1000=y 这类选项，说明启用的是 1000Hz
• 如果 /boot/config-$(uname -r) 不存在，说明内核配置未保留，需换方法

用 /proc/interrupts 观察 timer 中断增长速率

这是唯一能反映「当前实际中断触发频次」的运行时手段，尤其适用于 tickless 系统——它会显示真实发生的硬件 timer 中断次数，而非理论值。

操作步骤：

先记录初始值：
grep timer /proc/interrupts | awk '{print $2}'

等待 5 秒后再次执行相同命令，两值相减再除以 5，结果即为近似实时 HZ。

Linuxdo Application

为 Linux.do 注册撰写高通过率、去 AI 化的中文小作文。进行自适应调查以了解申请人的真实背景，...

下载

• 注意：输出中 timer 行可能有多个字段（如 LOC、TRM），要确认是 IRQTMR 或带 timer 字样的那行，不同内核版本命名略有差异
• 在深度 idle 状态下，该值可能远低于 CONFIG_HZ，这是 tickless 正常行为，不是故障
• 如果某 CPU 核上 timer 中断数长期不增长，可能是该核被 isolcpus 隔离或处于 offline 状态

别把 CLK_TCK 或 sysconf(_SC_CLK_TCK) 当成内核 HZ

很多教程混淆这两个概念：CLK_TCK 是用户空间约定俗成的时钟滴答单位，固定为 100，和内核实际中断频率无关。

验证方式：

getconf CLK_TCK → 总是输出 100
python3 -c "import os; print(os.sysconf('SC_CLK_TCK'))" → 同样是 100

• 它只用于 times(2)、/proc/stat 中的进程时间统计换算，比如把 jiffies 转成秒
• 哪怕内核编译为 CONFIG_HZ=1000，用户态看到的 CLK_TCK 仍是 100
• 试图用它反推内核定时器频率，必然出错

/proc/timer_list 不反映频率，只反映活跃定时器状态

这个文件常被误当作“查看定时器频率”的入口，但它其实列出的是所有已注册的高/低分辨率定时器实例，包括 softirq、per-CPU 定时器、hrtimers 等，不包含任何全局触发频率信息。

例如执行：
head -n 20 /proc/timer_list

你会看到类似：

timer:           ksoftirqd/0<br>
expires:         4294967295<br>
function:        run_ksoftirqd

• 这里 expires 是 jiffies 值，不是时间点，更不是频率
• 它适合排查某个定时器是否卡住、是否重复注册，但不能回答“每秒触发多少次”这个问题
• 真正想看硬件 timer 中断源，还是得回 /proc/interrupts

真正难判断的不是数值本身，而是“你到底想确认什么”：是内核编译设定的理论基准（CONFIG_HZ），还是当前负载下真实的中断发生密度（/proc/interrupts 差值），抑或某个特定软定时器的调度节奏（需结合 timer_list + perf 抓取）。三者完全不同，混用会导致结论完全偏离。