プロセスCPUの合計がtop / htopに示されている総CPU消費量よりも高いです。

プロセスCPUの合計がtop / htopに示されている総CPU消費量よりも高いです。

どちらもそのように低いCPU使用率をtop/htop報告するのはなぜですか?/proc/statプロセスCPU使用率の数値(スクリーンショットでは67.5%)が正しいようです。 ここに画像の説明を入力してください。

時々、次の予想される結果が表示されます。 ここに画像の説明を入力してください。

いくつかの詳細: Linux(カーネルバージョン4.19.0)はZynq 7z010(デュアルコアARM Cortex-A9プロセッサ)で動作します。信号処理アプリケーション(server.elfスクリーンショットを参照)は、ほとんどのリソースを消費します。ほとんどの処理は2つのスレッドで発生します。 1つはReceiver_010ミリ秒ごとに目覚めるスレッド、もう1つはSpectrum_017ミリ秒ごとに目覚めるスレッドです。これらのスレッドは SCHED_FIFO スケジューラを使用して予約されます。

ベストアンサー1

私は何が起こっているのかを発見しました。 Linuxカーネルドキュメント(https://www.kernel.org/doc/html/latest/admin-guide/cpu-load.html/proc/stat)は、(top/このデータを使用して)htopに表示されるデータの収集方法を説明します。

タイマー割り込みがシグナルを受け取るたびに、カーネルはその瞬間にどのタイプのジョブが実行されているかを確認し、そのジョブタイプ/ステータスに対応するカウンタをインクリメントします。この問題は、システムが2つのタイマー割り込みの間でさまざまな状態を複数回切り替えることができるが、カウンタは最後の状態に対してのみ増加することです。

前述のように、私の場合、ほとんどのデータ処理は短いバースト(2..4msでチャンク処理を完了するのに十分です)で定期的に(10msごとに)発生します。動作は例です(https://www.kernel.org/doc/html/latest/admin-guide/cpu-load.html#example) - すべての処理はシステム状態サンプル間で行われるため、システムは常にアイドル状態であると考えます。

 system state sampled in timer interrupt (10ms period on my system)
     |                                        |
     v                10ms                    v
...--|----------------------------------------|-------------------------...
           ^    3ms   ^             7ms             ^   3ms    ^
   sleep   |  active  |            sleep            |  active  |  sleep
...------> | <------> | <-------------------------> | <------> | <------...

/proc/[pid]/stat他のプロセスもCPUを使用しているため、データ処理を処理するプロセス(列に示されているのと同じ情報)のCPU使用率を計算するためにカウンタを使用してtopこの問題を解決しましたが、私の場合はCPU使用率は無視できます。%CPU

おすすめ記事