chrtLinuxには、コマンドラインを使用してプロセスに設定できるいくつかの予約オプションがあります。このうちどれが…どれか分からないようですSCHED_BATCH。実際、その説明はいくつかのソースから矛盾しています。しかしその前に、さまざまな説明がこれを参照しているので、すべての計画オプションについて私が得た事実を要約しますSCHED_BATCH。
SCHED_FIFO基本的に、SCHED_RRすべてのリアルタイムスケジューリング戦略にはいくつかの違いがありますが、ここではほとんど問題がなく、常に他のプロセスよりも先に実行されます。
SCHED_OTHERnice各プロセスの値に基づいて優先順位を指定する基本ポリシー。
SCHED_DEADLINESCHED_FIFO- まだ完全に理解していません。実行タイマーが設定されていますが、実際にはもっと近いように見え、SCHED_FIFOそのタイマーに達すると実際に/ taskを先取りすることもできます。SCHED_RR
SCHED_IDLE- デフォルトでは、「CPUがアイドル状態のときのみ予約」します。ここでは問題ありません。
今SCHED_BATCH私はこれがかなり議論の余地があると思います。一方ではオリジナル実装ノートSCHED_IDLE2002年現在、ユーザーコードとカーネルコードと本質的に同じですSCHED_OTHER（プロセスが予約されていないため、カーネルリソースロックが発生するのを防ぐため）。内部に男性の記事本質的に同じとは言えますが、SCHED_OTHERCPUバインディングと見なされるため、いくつかのペナルティがあります。
今、これら2つのSCHED_BATCH説明は互いに一致しません。どちらが真実ですか？SCHED_BATCHどこかに再実装されましたか？または、誰かがSCHED_BATCHMAN記事を書くときに誤解を起こした可能性がありますか？どんな説明が正しいですか？
アップデート：追加研究：
もう少し掘り下げてこれを見つけました。カーネルスケジューラドキュメント、または採掘を通して予約ソースSCHED_BATCHと同じコードで処理されているようですSCHED_OTHER。
私もテストしました。良い19を使用しても負荷が高いため、実際に他のプロセスを制限するプロセスは1つありますが、デフォルト設定がありますSCHED_OTHER。私は設定しましたが、SCHED_IDLE他のプロセスの調整の問題は消えました...そして、SCHED_BATCH同じプロセス（同じ19の設定で）を試すことにしました。驚くべきことにSCHED_BATCH、他のプロセスに制限はありませんSCHED_IDLE！
ただし、上記のリンクによると、SCHED_IDLEと同じコードで処理できますが、優先順位が非常に低いようです。どのような状況で使用されるのかはまだわかりません。SCHED_OTHERSCHED_BATCH慢性疲労症候群（これがSCHED_OTHER主な実装です。）この場合は、以下を使用します。カーネル/sched/idle.c実装する。
私はまだ決定的な答えを持っていません、テストとドキュメントもまだ私には大きな意味がありません。テストの結果、SCHED_BATCH実際と同じように機能することがわかりましたが、SCHED_IDLEすべての文書はSCHED_OTHER実際と同じように機能する必要があることが示されています。
ベストアンサー1
SCHED_BATCH
~から人々が準備したもの（7）、についてSCHED_BATCH：
... このポリシーを使用すると、スケジューラは常にスレッドが CPU にバインドされていると想定します。したがって、スケジューラは、スリープ動作に小さなスケジューリングペナルティを適用し、スレッドがスケジューリング決定にわずかに悪影響を及ぼすようにします。
明らかに、CFSスケジューラは、CPU集約的であると考えられるスレッドに「小さなペナルティ」を課します。 Linuxのソースコードを見ると、SCHED_BATCH1つの場所のスケジューラの動作にのみ影響することがわかります。今すぐkernel/sched/fair.c:yield_task_fair()
static void yield_task_fair(struct rq *rq)
{
…
if (curr->policy != SCHED_BATCH) {
update_rq_clock(rq);
/*
* Update run-time statistics of the 'current'.
*/
update_curr(cfs_rq);
/*
* Tell update_rq_clock() that we've just updated,
* so we don't do microscopic update in schedule()
* and double the fastpath cost.
*/
rq_clock_skip_update(rq);
}
set_skip_buddy(se);
}
関数名で判断すると、現在のスレッドを生成する（そして次のスレッドを選択することもできる）関数のようです。現在CPUで実行されているスレッド（）がcurrCPUから削除（「生成」）され、他のスレッドでCPUを使用できるようになります。スケジュールポリシーcurrに従って実行されている場合、SCHED_BATCH一部のランタイム統計は更新されませんcurr。
CFSの観点から統計を更新しないと、スレッドはCPUを大量に使用し、結果的にCFSがスレッドを好まないと考えられます。
SCHED_BATCHとSCHED_IDLE
SCHED_BATCHとの違いについてはSCHED_IDLE：2つは実際には非常に異なります。まず、SCHED_IDLEスレッドただ空きCPUがあれば実行します。したがって、スレッドは進行を保証しませんSCHED_IDLE。システムが他のスレッドによって100％使用されている場合、SCHED_IDLEスレッドは実行されない可能性があります。SCHED_BATCH通常のCPU多重化に参加するため、継続が保証されているスレッドの場合はそうではありません。
さらに、Linux> = 5.4では、SCHED_IDLEスレッドを実行しているCPUはCFSスケジューラの観点からアイドル状態と見なされます。これは重要な意味を持ちます。スレッド以外のSCHED_IDLEスレッドが実行可能になると、スケジューラは次のことを実行できます。まもなくスレッドを作成しSCHED_IDLE、SCHED_IDLEスレッドではなくスレッドをその上に置きます。また、見ることができます「SCHED_IDLEを編集」：LWN.net（2019-11-26）。
これSCHED_BATCHにより、他の操作を「調整解除」することもできます。それはおそらく、SCHED_BATCHスレッドが受け取るペナルティがそれをするのに十分であるからです。また、kernel/sched/idle.c直接関連していないSCHED_IDLEこのファイルには、CPUをアイドルモードにするスケジューラ固有のコードのみが含まれています。SCHED_OTHER、SCHED_BATCH そして SCHED_IDLEこれはすべてLinux CFSスケジューラのスケジューリング戦略です（kernel/sched/fair.c）。