これは以下に関連しています。この問題ところで、あまり満足のいく答えが出てこないので、新しい質問をしてみることができると思いました。
このスクリーンショットは、1つのコアが100％利用されているが、かなりの量のCPUを使用するプロセスがないことを示すhtopを示しています。
私はこれが未知の理由でカーネルがあまりにも多くの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が時間を費やしている場所を見つけて、リストされた機能の1bpftrace -e 'kprobe:acpi_ps_parse_aml /cpu == 0/ { printf("%d\n", tid); }'つのカーネルスレッドIDを見つけました。問題のスレッドはということが判明しkworker/0:3-kacpi_notify、一部のインターネット検索を通じて他の人もそのカーネルスレッドと同様の問題を経験したという事実が明らかになりました。