競合しないcpuset内のスレッドに対するスケジューラの優先順位とポリシーの影響がある場合、どのような影響がありますか？

私は、cgroupを使用して2つのcpu_exclusive cpusets、AとBを作成し、すべてのユーザースレッドとすべての非バインドカーネルスレッドをcpuset Aに接続されたcgroupに移行したLinuxシステムを持っています。cpusetAで実行されているものは、さまざまなスケジューラポリシーを持っています優先順位が異なり、cpuset Aで実行されているスレッドの数は、cpuset Aのコア数よりも多くなります。

cpuset Bに接続されているいくつかの非常にアクティブなプロセスもあります。これらのプロセス全体のユーザースレッドの総数は、cpuset Bで排他的に使用可能なコアの数を超えることはありません。目的は、cpusetで実行されるこれらの重要なタスクをシールドすることです。マシンの他のアクティビティからのBと、処理の待ち時間を最小限に抑えるため。

このような設定で、cpuset Bで実行されているユーザースレッドのスケジューリングポリシー/優先順位は、目に見える影響を及ぼしますか？言い換えると、B cpusetスレッドのスケジューリングポリシーをデフォルトのSCHED_OTHERからSCHED_FIFOまたはSCHED_RRに変更すると、良い結果も悪い結果も発生しますか？

スケジューラはcpuset Bで実行されている各スレッドに独自の専用コアを割り当てることができるため、答えは「いいえ」のように見えます。優先順位を付けたりスケジュールしたりするものは何もないため、Bのポリシーと相対的な優先順位はありません。 cpusetスレッドは重要ではありません。一方で、バインドされたカーネルスレッドと「スケジューラードメイン」の問題があること、そしておそらく私が考慮していない他のこともあります。

オーバープロビジョニングされた排他的cpusetで実行されているスレッドのスケジューリングポリシーと優先順位は、実際的な意味で重要ですか？

使用されるタイムスライスは、特定のコアを各PIDにロックしない限り、キャッシュの永続性を必要とするCPU集中型のジョブにとって重要になります。スケジューラポリシーSCHED_BATCHを使用してタイムスライスを増やし、場合によってはパフォーマンスを最大300％向上させると同時に、インタラクティブな応答性を低下させることができます。より小さいタイムスライスの反対の効果は、SCHED_RRで発生します（スループットは低下しますが、リアルタイムの応答性は向上します）。

schedtoolを使用して、セットBのすべてのPIDに特定のPIDのポリシーを単一のコマンドとして設定できます。また、特定のPIDを特定のコアにロックするために使用することもできます。これにより、キャッシュの永続性はタイムスライスに依存しなくなるため、最適なソリューションになりますが、PIDごとに個別のschedtoolコマンドを実行する必要があるため、これはより多くの労力を要します。

各プロセスに独自のコアがある場合、優先順位の制約はありません。

ただし、15分ごとに実行するのに30分かかるプロセスをスケジュールすると、プロセスが重複し始めるため、優先順位を付ける必要が生じ始めます。

ただし、「最適な」スケジュールポリシーはありません。

彼らは本当にあなたが達成したいことに依存しています。しかし、最初は、デフォルトのSCHED_OTHERのままにしておき、しばらくの間、より専門的なものを試す前に観察します。