私は、バックグラウンドで長期実行コンパイルタスクを頻繁に実行するデスクトップシステムを実行しています。 FPSを大幅に下げることなく、ランタイムにCPUベースのゲームをプレイしたいと思います（ゲームは8コアのうち4つしか使用しません）。
stress -c $(nproc)2つのプロセスで簡単なテストシナリオを設定しました。
Niceはもはや最新のLinuxディストリビューションでは機能しなくなるため（特に実際のユースケースでは）、ジョブの優先順位を付ける最善の方法はSCHED_IDLE予約ポリシーを使用することです。
そのため、1つはSCHED_IDLE（区別のために重要ではない1）に設定し、もう1つはSCHED_OTHERを使用して定期的に実行するように設定しました。
予想通り、0.1 us, 0.1 sy, 99.8 ni, 0.0 idバックグラウンドジョブが実行されているときと両方が99.5 us, 0.2 sy, 0.3 ni, 0.0 id実行されているときにCPU使用率がシミュレートされます。
しかし、この違いはゲームにうまく適用されません。バックグラウンドプロセスなしでゲームを正常に実行すると83FPSになり、SCHED_OTHERバックグラウンドジョブでゲームを実行すると非常に可変的な35FPSになり、SCHED_IDLEではかなり安定した60FPSが生成されます。 。
必要に応じて利用可能なCPUリソースをほぼ100％使用できるにもかかわらず、ゲームのパフォーマンスが低下するのはなぜですか？
以前のアイドルコアのアクティビティによる低ブースト頻度とL3キャッシュの輻輳が予想される10％未満のパフォーマンス低下に近づくにはどうすればよいですか？
（もちろん、一般的にコンパイルパフォーマンスの低下はありません。他の作業をしないときは、できるだけ早く作業をしたいと思います。make -j1技術的にはそうすることができることを知っています。）