为何修改CONFIG_HZ后udelay函数计时出现不准确问题？

我在编写Linux驱动时使用了udelay()函数，将内核配置中的CONFIG_HZ从100修改为1000后，驱动出现异常，最终发现udelay()的计时不准确。

查看ARM架构下的udelay实现代码：

// arch/arm/include/asm/delay.h
#define MAX_UDELAY_MS 2
 
#define udelay(n) \
(__builtin_constant_p(n) ? \
((n) > (MAX_UDELAY_MS * 1000) ? __bad_udelay() : \
__const_udelay((n) * ((2199023U*HZ)>>11))) : \
__udelay(n))

原本使用udelay(10)时驱动运行正常，但修改CONFIG_HZ为1000后，必须改为udelay(500)才能正常工作。注意到udelay的实现中使用了HZ，请问为何修改CONFIG_HZ会导致udelay计时不准确？

核心问题：旧版ARM udelay实现错误依赖CONFIG_HZ #

你看到的这个udelay实现是早期Linux内核中的遗留代码，它错误地将CONFIG_HZ（内核时钟中断的每秒触发次数）作为微秒延迟的计算基准，而不是使用CPU的实际运行时钟频率，这直接导致CONFIG_HZ的变更会破坏延迟计时的准确性。

具体计算逻辑拆解 #

我们聚焦__const_udelay的参数计算部分：

(n) * ((2199023U*HZ)>>11)

• 2199023U是一个近似系数，原本用于将微秒数转换为CPU周期数（对应2^31 / 1000000，便于在32位系统下做整数运算）。
• 但代码中额外引入了HZ相乘，再右移11位（等价于除以2048）。这就把内核中断频率和CPU周期计算绑定在了一起：
  • 当CONFIG_HZ=100时，参数为 n * (2199023 * 100) >> 11
  • 当CONFIG_HZ=1000时，参数变为 n * (2199023 * 1000) >> 11，是原参数的10倍
• __const_udelay内部通过循环消耗CPU周期实现延迟，参数越大，循环次数越多，实际延迟时间就越长。

对应你的现象 #

原本udelay(10)在HZ=100时产生的延迟，在HZ=1000时，相同参数会产生10倍时长的延迟。你需要设置udelay(500)才恢复正常，说明你的场景中实际需要的延迟被旧实现的错误计算放大，本质还是HZ引入的计算偏差。

为什么会存在这种错误？ #

这个实现是早期ARM内核缺乏可靠CPU时钟频率获取接口时的临时方案，后来的内核版本已经完全修复了这个问题——新版udelay会直接读取CPU的实际时钟频率（通过架构定时器或CPU时钟寄存器）进行计算，不再依赖CONFIG_HZ。

解决办法 #

1. 升级内核：使用较新版本的Linux内核，其udelay实现已脱离CONFIG_HZ的依赖，计时精度不再受内核中断频率影响。
2. 手动修正宏定义：如果无法升级内核，可修改delay.h中的宏，移除HZ相关计算，根据你的CPU主频重新计算系数。例如，若CPU主频为F MHz，1微秒对应F个CPU周期，可将系数调整为与F匹配的数值，而非绑定HZ。

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