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

B站影视 2025-01-18 21:12 3

摘要:本文作者致力于将基于 PXA166 的 Chumby 8 设备从 Linux 2.6.28 版本升级到现代 6.x 版本,然而,在看似一切硬件外

【CSDN 编者按】每一次对旧设备的升级都仿佛是一场跨越时代的冒险。

本文作者致力于将基于 PXA166 的 Chumby 8 设备从 Linux 2.6.28 版本升级到现代 6.x 版本,然而,在看似一切硬件外

设都已顺利工作的背后,却出现了一个令他费解的谜团——CPU 使用率居高不下,甚至时常飙升至 100%。

通过深入分析内核源码、探讨定时器寄存器的读取方式,本

文作者最终找到了隐藏在代码中的 bug 并成功修复,该补丁也已被合并到了 Linux 6.2 版本中。

.com/2024/04/why-is-my-cpu-usage-always-100-upgrading-my-chumby-8-kernel-part-9/

作者 | Doug Brown 翻译 | 郑丽媛

出品 | CSDN(ID:CSDNnews)

一直以来,我都在记录把我那台基于 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 8 2 root IW 0 0% 0% [kworker/0:0-lib] 22 2 root IW 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 :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/

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

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

来源:CSDN

相关推荐