CFS入門 @xorphitus (2015-12) 

これまでのあらすじ ● 最初は ○ BFS (Brain Fuck Scheduler): プロセススケジューラ ○ BFQ (Buget Fair Queueing): I/Oスケジューラ ● の、どっちかの話をしようと思った ○ yaourt -S linux-ck で両者対応パッチの当たったカーネルが入るよ ● しかしところが ● 「あれ、そもそも自分、スケジューラ全然分かってねえや」 ● 「よし基本っぽいところから勉強しよう」 ● 「じゃあスタンダードっぽいプロセススケジューラでいいや」←いまここ 

いやー、今回やろうと思ってたんだけどなー ● Linux プロセススケジューラ基礎 ● O(1) スケジューラとの比較 ● BFS との比較 ● カーネルコードリーディング ● 実際に色んなプロセススケジューラを 動かしてみた 間に合いませんでした・・・ 

そもそもの基本概念 CFS 以前に、CPUがマルチタスクをどうやって捌いてるかって話 基本的には何となく知っての通り、N個のタスクを随時切り替えつつ実行する task 1 task 2 task 3 1 2 3 4 5 6 

んで、CFS Kernel 2.6.23 から導入されたプロセススケジューラ 歴史ありますね 

Linux Kernel 4.2.7 の場合 2009年のこの記事を最初参考にしていたが http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch09c.html 現在はちょっと変わってるっぽい (パラメータチューニング程度？) https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/kernel/sched/fair .c?id=refs/tags/v4.2.7 sched/fair.c と、ファイル名まで FAIR である 

一周にかける時間をまずは均等に考える CFS の場合、一周にかける時間 (period) は「基本的には」 sysctl_sched_latency = 6ms * (1 + log(コア数)) period = sysctl_sched_latency task 1 ・・・ period(ms) task n task 3 task 2 

各タスクにかける時間に重みをつける nice値を考慮すると、一タスク当たりの時間 (slice) は weight = 1.25 ^ (-nice) slice = period * weight / total_wight task 1 ・・・ task n task 3 task 2 nice値の小さいものが 幅をきかせる period(ms) slice 

ただし period には下限がある タスクが増えすぎると slice が小さくなりすぎコンテキストスイッチのコストがやばいため (nr_running は稼働中プロセス数) sysctl_sched_min_granularity = 0.75 ms * (1 + log(コア数)) static u64 __sched_period(unsigned long nr_running) { u64 period = sysctl_sched_latency; unsigned long nr_latency = sched_nr_latency; if (unlikely(nr_running > nr_latency)) { period = sysctl_sched_min_granularity; period *= nr_running; /* ここで「最低 slice * タスク数」を period に設定している */ } return period; } 

タスクの実行順序はどうなるのか 赤黒木で順序を保持してるらしい ● 探索、挿入、削除の最悪計算時間が O(log n) ● 探索速度だけで見るとO(1) スケジューラ に劣る ○ ただしこいつはタスク実行が偏る 「基本は」以下の式で算出された vruntime の小さい順に並ぶ vruntime = そのタスクが動作している時間 + 1.25 ^ nice つまり、nice 値を考慮しつつも、長いこと専有しているやつがのさばらないように調整さ れる → FAIR 

タスクの順序、例外事項 vruntime によって完全な公平性が保たれるかというと、案外そうでもない Sleep してるタスクが問題を起こすので、実行順序に例外が設けられている 続きはまた今度