CFS入門

CFS に入門しようとしました。

Transcript

1. CFS入門 @xorphitus (2015-12)
2. これまでのあらすじ • 最初は ◦ BFS (Brain Fuck Scheduler): プロセススケジューラ ◦ BFQ (Buget Fair Queueing): I/Oスケジューラ • の、どっちかの話をしようと思った ◦ yaourt -S linux-ck で両者対応パッチの当たったカーネルが入るよ • しかしところが • 「あれ、そもそも自分、スケジューラ全然分かってねえや」 • 「よし基本っぽいところから勉強しよう」 • 「じゃあスタンダードっぽいプロセススケジューラでいいや」←いまここ
3. いやー、今回やろうと思ってたんだけどなー • Linux プロセススケジューラ基礎 • O(1) スケジューラとの比較 • BFS との比較 • カーネルコードリーディング • 実際に色んなプロセススケジューラを 動かしてみた 間に合いませんでした・・・
4. そもそもの基本概念 CFS 以前に、CPUがマルチタスクをどうやって捌いてるかって話 基本的には何となく知っての通り、N個のタスクを随時切り替えつつ実行する task 1 task 2 task 3 1 2 3 4 5 6
5. んで、CFS Kernel 2.6.23 から導入されたプロセススケジューラ 歴史ありますね
6. 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 である
7. 一周にかける時間をまずは均等に考える CFS の場合、一周にかける時間 (period) は「基本的には」 sysctl_sched_latency = 6ms * (1 + log(コア数)) period = sysctl_sched_latency task 1 ・・・ period(ms) task n task 3 task 2
8. 各タスクにかける時間に重みをつける nice値を考慮すると、一タスク当たりの時間 (slice) は weight = 1.25 ^ (-nice) slice = period * weight / total_wight task 1 ・・・ task n task 3 task 2 nice値の小さいものが 幅をきかせる period(ms) slice
9. ただし 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; }
10. タスクの実行順序はどうなるのか 赤黒木で順序を保持してるらしい • 探索、挿入、削除の最悪計算時間が O(log n) • 探索速度だけで見るとO(1) スケジューラ に劣る ◦ ただしこいつはタスク実行が偏る 「基本は」以下の式で算出された vruntime の小さい順に並ぶ vruntime = そのタスクが動作している時間 + 1.25 ^ nice つまり、nice 値を考慮しつつも、長いこと専有しているやつがのさばらないように調整さ れる → FAIR
11. タスクの順序、例外事項 vruntime によって完全な公平性が保たれるかというと、案外そうでもない Sleep してるタスクが問題を起こすので、実行順序に例外が設けられている 続きはまた今度