CPU「离奇」飙到 100%!开发者挖出 Linux 内核 16 年老 Bug:这么多年竟无人发现?

一直以来，我都在记录把我那台基于 PXA166 的 Chumby 8 从 Linux 2.6.28升级到现代 6.x 版本的经历。到目前为止，这个项目中的所有主要硬件外设都已正常工作。不过，当我运行 top 命令时，发现了一个很奇怪的现象：CPU 的使用率总是非常高，且原因不明。

Mem: 47888K used, 55968K free, 168K shrd, 3116K buff, 27480K cachedCPU: 100% usr 0% sys 0% nic 0% idle 0% io 0% irq 0% sirqLoad average: 0.00 0.00 0.00 2/51 269 PID PPID USER STAT VSZ %VSZ %CPU COMMAND 267 200 root R 2936 3% 100% top 100 1 root S 12240 12% 0% /sbin/udevd -d 1 0 root S 2936 3% 0% init 200 1 root S 2936 3% 0% -sh 65 1 root S 2936 3% 0% /sbin/syslogd -n 71 1 root S 2936 3% 0% /sbin/klogd -n 34 2 root SW 0 0% 0% [irq/56-mmc0] 10 2 root IW 0 0% 0% [kworker/0:1-eve] 11 2 root IW 0 0% 0% [kworker/u2:0-ev] 41 2 root IW< 0 0% 0% [kworker/0:2H-kb] 8 2 root IW 0 0% 0% [kworker/0:0-lib] 22 2 root IW< 0 0% 0% [kworker/0:1H-mm] 32 2 root SW 0 0% 0% [irq/55-mmc1] 14 2 root IW 0 0% 0% [rcu_preempt] 17 2 root IW 0 0% 0% [kworker/u2:1-ev] 15 2 root SW 0 0% 0% [kdevtmpfs] 27 2 root IW 0 0% 0% [kworker/0:2-pm] 2 0 root SW 0 0% 0% [kthreadd] 13 2 root SW 0 0% 0% [ksoftirqd/0] 3 2 root SW 0 0% 0% [pool_workqueue_]

你看，这真是太奇怪了！为什么 top 命令会占用我这么多的 CPU 资源？尤其是第二行，直接显示 usr（用户空间）占用了 100%。有时候，CPU 使用率还会显示为 50% usr 和 50% sys（系统空间），有时又会显示 sys 占用 100%。只有在极少数情况下，top 命令才会如我预期般显示 0% 的使用率。之前 2.6.28 版的 Linux 内核就没有这个问题，所以我猜新版内核中肯定有些不同之处。

我开始猜测问题可能出在哪里，不过也只是瞎猜：也许是我之前成功配置的某个驱动完全占用了 CPU，导致看起来像是其他进程消耗了全部的 CPU；又或者是我缺少某种 CPU 空闲支持，导致处理器一直处在 100% 的高负载下运行，无法休息；还有可能是主线内核中缺少了某些电源管理支持等……无论如何，我需要找到一种方法来缩小问题范围。

确认 bug 并非出自最新的 Linux 6.x

为了解决这个难题，我想到的第一步就是回溯过往。几年前，我曾尝试让 Linux 3.13 在 Chumby 8 上运行，但由于时间不够和经验不足，我最终放弃了这个项目。不过，这段经历在今天变得非常有用，因为我可以尝试启动旧的 3.13 版内核，看看它是否也存在相同的问题。

结果不出所料，3.13 版内核也有完全相同的问题。这一发现很有价值，因为它表明问题并非出自最新版本。而且，由于在那个旧内核中运行的驱动程序并不多，这也排除了很多很多可能的原因。于是，我告别了旧内核，并感谢它提供的线索。

随后，我尝试通过启用 CONFIG_PROFILING 来对现代内核进行分析，并在内核命令行中添加了 profile=2。同时，我还确保将 Linux 编译目录下的 System.map 文件复制到了 Chumby 的 /boot 目录中。这样一来，我就做好了性能分析的准备。

readprofile -r # resets the counterstop # run top and wait for a while, then type q to exitreadprofile # this prints out the final profiling results

readprofile 的结果非常有趣。整个输出太长，无法在这里全部展示，但以下是它输出的最后一部分：

... 38 lock_is_held_type 0.0888 8 debug_lockdep_rcu_enabled 0.1000 4 __schedule 0.0019 1 preempt_schedule_irq 0.0068 1 __mutex_unlock_slowpath 0.0012 1 mutex_trylock 0.0022 3 __mutex_lock 0.0017 1 down_read_killable 0.0093 3974 default_idle_call 24.2317 4 _raw_spin_lock 0.0435 1 _raw_spin_lock_irq 0.0078 1 _raw_spin_lock_irqsave 0.0081 29 _raw_spin_unlock_irq 0.2788 118 _raw_spin_unlock_irqrestore 0.8429 0 *unknown* 4722 total 0.0006

从总计来看，default_idle_call 占用了绝大多数时间，这在我看来很正常。经过这次测试，我对那些外设驱动程序不再怀疑，确定 CPU 确实是处于空闲状态——但为什么 top 命令不这么认为呢？

为了弄清楚 default_idle_call 做了什么，我追踪到了它最终调用的 arch_cpu_idle 函数。在 ARM 架构上，如果没有定义 arm_pm_idle 函数，则会调用 cpu_do_idle。而在这个特定的 ARM 设备上，arm_pm_idle 未被使用，因此我继续追踪 cpu_do_idle。最终，通过对编译后的 vmlinux 文件进行反汇编，我确认对于 PXA168 处理器而言，它调用了 cpu_mohawk_do_idle。

根据下面 Linux 6.8 版本的代码，这个函数看起来并不复杂：

ENTRY(cpu_mohawk_do_idle) mov r0, #0 mcr p15, 0, r0, c7, c10, 4 @ drain write buffer mcr p15, 0, r0, c7, c0, 4 @ wait for interrupt ret lr

它们基本上是相同的，只不过新内核还会清空写缓冲区。此外，我发现 2.6.28 版本的内核中并未定义 CONFIG_ENABLE_COREIDLE，这点差异比较大。为了确保万无一失，我用 objdump 又仔细检查了一下 2.6.28 内核：

c0207000 <cpu_mohawk_do_idle>:c0207000: e3a00000 mov r0, #0c0207004: e1a0f00e mov pc, lr

没错，2.6.28 版内核中确实没有“等待中断”的操作。这让我有了一些新思路，开始觉得自己可能找到了问题的关键。我试着将现代内核中的 cpu_mohawk_do_idle 函数修改得与旧版本完全相同，但说实话，这在逻辑上并不合理：移除一个“等待中断”指令，难道不会让 CPU 的空闲管理变得更差吗？我强迫自己暂时不去思考这些，反正试试看也没什么损失。

尽管我以为自己有了突破性的进展，但这个方向最终证明是一条死胡同。无论我在 cpu_mohawk_do_idle 中做了什么调整，top 依然显示 CPU 使用率为 100%——本以为我马上就要解决这个问题，瞬间又回到了原点。

从头理解 top 命令的工作原理

当我暂时放下这个问题后，我意识到自己的方法过于随意，缺乏逻辑性。因此，我决定换一种方式来处理这个问题。有一个简单的问题启发了我：top 究竟是如何计算并显示 CPU 使用率的？我突然发现自己对 top 的工作原理知之甚少，完全是凭感觉。于是，我查阅了 BusyBox 的源代码，试图理解它是如何工作的。

原来，top 所显示的所有信息都是来自 procfs，它挂载在 /proc 目录下。在源文件的开头，你可以看到一段注释：“在启动时，当前目录会切换到 /proc，所有的读取操作相对于该目录进行。”关于这个切换工作目录的操作，也在第 1150 行得到了确认。

top 所做的就是读取几个文件，包括 /proc/stat、/proc/meminfo，以及每个运行进程对应的 /proc/<pid>/stat 文件。在 BusyBox 的 top 实现中，遍历所有进程都是由 procps_scan 函数完成的。源代码中的注释提到，man 5 proc 可以提供更多关于这些文件内容的信息。于是我把重点放在了 /proc/stat 上，为它负责提供 top 输出第二行中显示的 CPU 负载分布情况，例如用户空间、系统空间和空闲时间等。

手册页中提到，/proc/stat 文件中以“cpu”开始的行包含了一系列数字，这些数字对应着 CPU 在不同状态下消耗的时间。以