cgroupを使用して2つのcpu_exclusive cpuset AとBを作成し、すべてのユーザースレッドとバインドされていないすべてのカーネルスレッドをcpuset Aに接続されたcgroupに移行するLinuxシステムがあります。 CPUset Aで実行されるものはスケジューラポリシーと優先順位が異なり、CPUset AのコアよりもCPUSet Aで実行されるスレッドが多いです。
さらに、CPUセットBには非常にアクティブな少数のプロセスが接続されており、これらのプロセスの総ユーザースレッド数は、CPUセットBで排他的に使用できるコア数よりも決して大きくはありません。目標は、CPUsetで実行される重要なタスクBをマシンの他のアクティビティから保護し、処理遅延を最小限に抑えることです。
これらの設定では、CPUset Bで実行されているユーザースレッドの予約ポリシー/優先順位が顕著な影響を与えますか？つまり、B cpusetスレッドのスケジューリングポリシーをデフォルトのSCHED_OTHERからSCHED_FIFOまたはSCHED_RRに変更すると、どのような結果（良い結果または悪い結果）が発生しますか？
答えは「いいえ」でなければならないようです。なぜなら、スケジューラはcpuset Bで実行される各スレッドを独自の専用コアに割り当てることができる必要があるため、優先順位やスケジューリングがないため、Bのポリシーと相対的な優先順位はcpusetスレッドは重要ではありません。一方、心配する必要があるバインドされたカーネルスレッドと「スケジューラドメイン」の側面があり、私が考慮していない他のことがあるかもしれません。
過剰プロビジョニングされた独自のCPUセットで実行されるスレッドのスケジューリングポリシーと優先順位は、実際の意味では重要ですか？
ベストアンサー1
使用されるタイムスライスは、特定のコアを各PIDにロックしない限り、キャッシュ永続性を必要とするCPU集約タスクにとって重要です。スケジューラポリシーSCHED_BATCHを使用すると、時間を増やすことでインタラクティブな応答性を減らし、最大300％のパフォーマンスを向上させることができます。 SCHED_RRはより小さい時間フラグメントの反対の効果を持ちます（処理量は減少しますが、リアルタイムの応答性は向上します）。
schedtool を単一のコマンドとして使用して、セット B のすべての PID に対して特定の PID のポリシーを設定できます。また、特定のPIDを特定のコアにロックするために使用できます。これは、キャッシュの永続性がもはやタイムスライスに依存しないため、最良の解決策になりますが、別の schedtool コマンドを実行する必要があるため、より多くの労力が必要です。