これは推測ですが、知識に基づいたものです - 分離された CPU を使用するため、スケジューラは、1 つの例外を除いて、自分自身のタスク以外のタスクをスケジュールしません - カーネルの vmstat コードには、それぞれに単一の作業キュー項目をスケジュールするタイマーがありますCPU は 1 秒に 1 回、メモリ使用量の統計を計算します。これは、毎秒スケジュールされているものです。
ワーク キュー コードは、コアが 100% アイドル状態の場合はワーク キュー カーネル スレッドをスケジュールしないように十分にスマートですが、単一のタスクを実行している場合はそうではありません。
これはftraceを使用して確認できます。sched_switch トレーサーが、1 秒ごとに 1 回程度切り替えるエンティティを示している場合 (値は最も近い jiffie イベントに丸められ、CPU がアイドル状態のときはタイマーがカウントされないため、タイミングが歪む可能性があります) は events/CPU_NUMBER タスクです。 (または古いカーネルの場合は keventd )、その原因は実際にvmstat_update関数がタイマーを設定して、イベントカーネルスレッドが実行するワークキューアイテムを毎秒キューに入れることであることがほぼ 100% です。
vmstat がタイマーを設定するサイクルは構成可能であることに注意してください。vm.stat_interval sysctlノブを介して他の値に設定できます。この値を大きくすると、メモリ使用統計の精度が低下しますが、このような中断の発生率が低くなります。
私は、隔離された CPU 作業負荷に対する中断のすべての原因を含む wiki を維持しています。CPU 上の単一のタスクが動的メモリを使用しない場合など、1 つの vmstat ワーク キューの実行と次の実行の間に変更がない場合、vmstat がワーク キュー アイテムをスケジュールしないようにするためのパッチも準備中です。割り当て。ただし、それがあなたに役立つかどうかはわかりません-それはあなたの仕事量に依存します.