Linuxのプロセススケジューラの歴史 v2.6.0~v2.6.22

以下動画のテキストです
https://youtu.be/iu35GUZ57gU

Transcript

1. Linuxのプロセススケジューラの歴史 v2.6.0~v2.6.22 Jan. 29th, 2022 Satoru Takeuchi Twitter: satoru_takeuchi 1
2. はじめに • Linuxカーネル(以下カーネル)のプロセススケジューラの歴史を振り返る • 対象バージョン: 最初のリリースv2.6.0からv2.6.22まで • 用語 ◦ タスク: カーネルのスケジューリング単位。プロセスあるいはスレッド ◦ LCPU: カーネルがCPUとして認識するもの(物理CPU or コア or スレッド) ◦ Current: LCPU上で現在動作中のタスク 2
3. V2.6: O(1)スケジューラ • コア部分のアルゴリズム総とっかえ ◦ 実行可能タスク数が nのときのスケジュール処理の計算量が O(1) ◦ 対話型タスクの優先動作 ◦ LCPUごとのランキュー ◦ 負荷分散 ◦ CPU affinity ◦ カーネルレベルスレッド 3
4. スケジュール処理の計算量がO(1) • ランキュー長が伸びてもスケジュール処理の速度が変わらない ◦ ランキューはActiveキュー、inactiveキューの2つ ◦ Activeキューの先頭からスケジュール。タイムスライスが切れたら inactiveキューへ移動 ◦ Activeキューが空になったら inactiveキューと切り替え 4
5. スケジューラの挙動: 初期状態 5 Runnable 10 Runnable 10 active expired t0 t1
6. activeキューの先頭タスクが動作 6 Runnable 10 Runnable 10 active expired t0 t1
7. t0がタイムスライスを使い果たす 7 Runnable 0 Runnable 10 active expired t0 t1
8. t0がexpiredキューに入る 8 Runnable 0 Runnable 10 active expired t0 t1
9. t1が動作 9 Runnable 0 Runnable 10 active expired t0 t1
10. t1がタイムスライスを使い果たす 10 Runnable 0 Runnable 0 active expired t0 t1
11. t1がexpiredキューの末尾に移動 11 Runnable 0 Runnable 0 active expired t0 t1
12. タイムスライスをチャージ 12 Runnable 10 Runnable 10 active expired t0 t1
13. activeキューとinactiveキューを入れ替え 13 Runnable 10 Runnable 10 expired active t0 t1
14. sleepから起床したタスクはactiveキュー末尾へ 14 Runnable 10 Runnable 10 inactive active t0 t1 Runnable 5 t2 おはよう
15. 優先度別ランキュー 15 nice値20のランキュー nice値-19のランキュー nice値0のランキュー … … active inactive active inactive active inactive … …
16. 高優先度ランキューの先頭から順番にスケジュール 16 nice値20のランキュー nice値-19のランキュー nice値0のランキュー 1 2 … … active inactive 3 4 active inactive 5 6 active inactive … …
17. 全activeキューが空になると… 17 nice値20のランキュー nice値-19のランキュー nice値0のランキュー … … active inactive active inactive active inactive … …
18. activeキューとinactiveキューをスイッチ 18 nice値20のランキュー nice値-19のランキュー nice値0のランキュー … … inactive active inactive active inactive active … …
19. 対話型タスクの優先動作 • 対話型タスク: bashやXなどの人間が直接やりとりするタスク • 課題 ◦ 実行可能タスク増加に伴い対話型タスク起床時のスケジュールが遅れる ◦ ユーザの体感レイテンシが長くなる • 対策: ヒューリスティックを入れる ◦ 単位時間あたりにsleepしている率が高いプロセスを対話型タスクとみなす ◦ 対話型タスクへの優遇 ▪ タイムスライスが切れると expiredキューではなくactiveキューに移す ▪ 内部的にnice値を下げる: タイムスライスは変化しない ▪ その一方、ずっと実行可能なタスクは優先度を下げる (最大5) 19
20. LCPUごとのランキュー • 個々のLCPUのスケジュールが他のLCPUと競合しない 20 active inactive active inactive • 優先度別ランキューはスペースの都合上省略 LCPU0 LCPU1
21. LCPUごとのランキューにまつわる問題 • ランキュー長が偏る 21 LCPU0 LCPU1 ランキュー長=4 忙しいんですけど あっそ ランキュー長=0
22. 負荷分散 • 負荷の高いLCPUから負荷の低いLCPUにタスクを移動 ◦ 負荷 ~= ランキュー長 ◦ のちに負荷はnice値やスケジューリングポリシーを考慮して重み付けするようになる • 動作契機 ◦ 新たにLCPUがアイドルになったとき ◦ 周期的に起動 22
23. ロードバランサ: 初期状態 • ランキュー長が偏る 23 LCPU0 LCPU1 ランキュー長=4 忙しいんですけど ランキュー長=0
24. バランス後 • ランキュー長が偏る 24 LCPU0 LCPU1 ランキュー長=2 ありがとう ランキュー長=2 しょうがねえなあ 移動
25. ロードバランサとNUMA • NUMAシステムの場合は2階層のバランス処理 1. NUMAノード間のバランス 2. ノード間LCPU間のバランス • のちにさらに階層が増えるがここでは割愛 25
26. ロードバランサの挙動: 初期状態 • 2ノード×2CPU(合計4LCPU)構成 26 t0 t1 t5 t4 t3 LCPU0 LCPU1 LCPU2 LCPU3 t2 node0 node1
27. 一番busyなnodeと暇なnodeを見つける • 27 t0 t1 t5 t4 t3 LCPU0 LCPU1 LCPU2 LCPU3 t2 node0 node1 タスク数4 タスク数2
28. 一番busyなnode内の一番忙しいLCPUを選ぶ • 28 t0 t1 t5 t4 t3 LCPU0 LCPU1 LCPU2 LCPU3 t2 node0 node1 タスク数3 タスク数1
29. 一番暇なnode内の一番暇なLCPUを選ぶ • 29 t0 t1 t5 t4 t3 LCPU0 LCPU1 LCPU2 LCPU3 t2 node0 node1 タスク数0 タスク数2
30. 一番busyなLCPUから一番暇なLCPUにタスクを移動 • 30 t0 t1 t5 t4 t3 LCPU0 LCPU1 LCPU2 LCPU3 t2 node0 node1 t2 移動
31. CPU affinity • タスクを動作させるLCPUの集合を決められる ◦ 用途: 全CPUで1つずつ動かしたいハートビート用タスクなど ◦ sched_setaffinity()システムコールやtasksetコマンドによって設定 31 T0 Affinity: 0, 1 T1 Affinity: 0 T2 Affinity: 1 LCPU0 LCPU1 × 移動可 〇 移動不可
32. 豆知識: CentOS 3のひみつ • 2.4系カーネルを採用 32 2.4
33. 魔改造カーネル • 実はO(1)スケジューラをバックポート済 33 2. 4 O(1)スケジューラ
34. 魔改造カーネルの欠点 • Upstreamへの追従が大変すぎて死ぬ 1. upstreamの新バージョンが出る 2. 全パッチから必要なものを抽出 3. 必要なパッチをバックポート 4. 1に戻る • 最近はどこもupstream firstを謳っており、こういうのは減っている 34 じゃあの
35. V2.6.12: cpuset • タスクのグループに割り当てられるCPUのリストやメモリ量などを制限 • アプリやユーザごとの資源管理に利用 • /dev/cgroup以下ファイルによって操作 35 Cpuset0 動作可能LCPUリスト: 0, 1 使用可能メモリ量: 100MB Cpuset1 動作可能LCPUリスト: 2, 3 使用可能メモリ量: 200MB t0 t1 t2
36. O(1)スケジューラの諸問題 • ヒューリスティック多すぎでコーナーケースが山ほどある ◦ 例: 応答性向上機能のせいでシステムが応答しなくなる 1. スリープと起床を繰り返すタスクを大量に起動 2. 一部タスクが対話的とみなされて優先度が最高に 3. 2で述べたタスクがタイムスライスを使い切ると activeキューに 4. 他のタスクは全く動けない • 実行可能タスク数が多いとなかなかCPU時間が回ってこない • タイムスライスの粒度が荒くて細かい制御ができない ◦ 粒度を増やすにはタイマー割り込みの回数を増やす必要がある ◦ 細かくすると割り込み回数が上がってシステム全体の性能が下がる 36
37. V2.6.2{0,1,2}の開発中あたり: RSDL vs CFS • 次期スケジューラの座を争って2つの新実装が激突 ◦ Rotating Staircase Deadline Scheduler by Con Kolivas ▪ 「今のスケジューラはエンプラ用途に特化しすぎ」とデスクトップ志向を目指した ◦ Completely Fair Scheduler(CFS) by Ingo Molnar ▪ RSDLに触発されて後追いで作られた ▪ 目標は全てのタスクを Completely Fair(完全に平等)に扱うこと 37 CFSがいいよ RSDLがいいよ
38. V2.6.23: CFSの勝利 • いったんは開発版カーネルにRSDLがマージされる • …が、最終的に安定版のv2.6.23にはCFSがマージされる 38 勝った 負けた
39. さらばCon Kolivas • Linuxカーネル開発引退表明 • ホームページに日本語の謎ダイイングメッセージを残す 39 さようなら、いままで魚をありがとう
40. まとめ 1. O(1)のスケジューラの導入 2. 負荷分散処理の改善 3. 対話型タスクの特別扱いとその課題 4. 次世代スケジューラの覇権争い 40