这与这个问题，但由于它确实没有任何令人满意的答案，我想我可以问一个新问题。
此屏幕截图显示 htop 指示一个核心利用率为 100%，但没有进程使用任何大量 CPU：
我认为这意味着内核出于某种未知的原因使用了这么多的CPU，但我还没有找到一个很好的方法来调查这个问题。 （现在考虑使用 eBPF）我认为这可能与我的磁盘加密和磁盘访问有关，但 iotop 没有显示任何重要的磁盘使用情况。我正在运行带有完全标准内核的 Arch Linux。
这个问题最近出现了几次，如果我重新启动，问题就会消失，并且总是需要至少几个小时的时间才能出现。
任何有关如何调试此问题或根本原因可能是什么的想法和建议都将非常受欢迎。
编辑：
所以这个新的屏幕截图显示 htop 设置为显示内核和用户线程，但对于高 cpu 使用率仍然没有明确的解释：
编辑2：
以下屏幕截图显示了bfptrace运行时的结果bpftrace -e 'profile:hz:99 /cpu == 0/ { @[kstack] = count(); }'。acpi_os_execute_deferred由于某种原因，内核似乎花费了大量时间。
答案1
终于找到了答案。事实证明这个问题是一样的这个问题有附加信息这里和这里。这些都没有提到 htop 显示零使用率的问题，因此这可能是一个不相关的问题。
正如上面的链接中所解释的，答案是使用sudo grep . -r /sys/firmware/acpi/interrupts/，然后使用echo "disable" /sys/firmware/acpi/interrupts/gpe6D来禁用有问题的中断（在我的情况下，附加最大数字的中断gpe6D）。
为了弄清楚这是问题所在，我bfptrace按照问题中的解释使用了内核堆栈跟踪并找出 cpu 花费时间的位置，然后bpftrace -e 'kprobe:acpi_ps_parse_aml /cpu == 0/ { printf("%d\n", tid); }'查找列出的函数之一的内核线程 ID。事实证明，有问题的线程是kworker/0:3-kacpi_notify，然后通过一些谷歌搜索发现其他人也对该内核线程遇到了类似的问题。