説明どおり一部(少し古い)記事,Linuxアイドル操作(PID = 0、CPUごとに1つ)実行する他のジョブがない場合に実行されます。スケジューラがこれを実行するには、アイドル操作の優先順位が最も低い必要があります。リンクされたLWN記事の前の記事には、次のように明確に記載Documentation/ftrace.txt
されています。
prio "140"は、優先順位が最も低いスレッド(pid 0)のアイドル操作用に予約されています。
これは意味がありますが、Linux 4.9では
# perf record -e sched:sched_switch sleep 1
# perf script
sleep 6526 [000] 362661.310842: sched:sched_switch: sleep:6526 [120] S ==> swapper/0:0 [120]
報告優先順位は120 swapper/0
(右括弧内)で上記と矛盾します。
これで、Linuxスケジューラはアイドルタスクをどのように処理しますか?コミットの変更ftrace.txt
(87d80de28、294ae4011)は役に立ちませんでした。
答え1
私に良いことがあります。回答LinuxカーネルメーリングリストのTill Smejkalでは:
アイドル操作には、CPUコアごとにアイドルスレッドのみを処理する独自の予約クラスがあります。このスケジューリングクラスは、カーネルで使用可能なスケジューリングクラスの中で最も優先順位が低いです。これは、CPUがスケジュールするジョブがあるかどうか、ジョブの切り替え時に要求される予約クラスのリストの最後のクラスであることを意味します。したがって、アイドル操作はCFSによって管理されていないため、適切な値や優先順位はありません(または少なくとも今は重要ではありません)。より多くの情報を含むことができるカーネルソースコードの興味深いファイルは、、
kernel/sched/idle_task.c
とkernel/sched/sched.h
ですkernel/sched/core.c
。
しかし、私の理解によれば、タスクはCFSで管理されていないにもかかわらず優先順位を持つことができます。リアルタイムタスク(SCHED_FIFO
および)は、POSIXが要求するように意味のある優先順位SCHED_RR
に属し、確かに意味のある優先順位を持ちます。rt_sched_class
static inline int rt_policy(int policy)
{
return policy == SCHED_FIFO || policy == SCHED_RR;
}
しかし、今は準備に焦点を当てています。クラス次の構造で実装される優先順位は、ポインタを介して次の順序で連結されますconst struct sched_class
。.next
stop_sched_class
dl_sched_class
rt_sched_class
fair_sched_class
idle_sched_class
接続リストはkernel/sched/sched.h
()によって巡回されます。
#ifdef CONFIG_SMP
#define sched_class_highest (&stop_sched_class)
#else
#define sched_class_highest (&dl_sched_class)
#endif
#define for_each_class(class) \
for (class = sched_class_highest; class; class = class->next)
上記の引用で述べたように、各クラスは次のように実行可能なタスクを提供するpick_next_task()
必要があります。kernel/sched/core.c
again:
for_each_class(class) {
p = class->pick_next_task(rq, prev, rf);
if (p) {
if (unlikely(p == RETRY_TASK))
goto again;
return p;
}
}
これは、アイドル操作が優先順位値(一部のデフォルト値)を持つが、予約決定中にこれを参照しないことを意味しますidle_sched_class
。
上記は優先順位の値を変更する問題を開いていますが、これは現在のところ歴史的な問題です(上記のコード引用はLinux 4.16からのものです)。