Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Linuxのプロセススケジューラの歴史 v2.6.0~v2.6.22
Satoru Takeuchi
PRO
January 29, 2022
Technology
0
30
Linuxのプロセススケジューラの歴史 v2.6.0~v2.6.22
以下動画のテキストです
https://youtu.be/iu35GUZ57gU
Satoru Takeuchi
PRO
January 29, 2022
Tweet
Share
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
KubeCon EU 2022 Ceph Intro & Rook Deep Dive
sat
PRO
0
8
YAMLを書くだけで構築できる分散ストレージ
sat
PRO
0
190
実践オブザーバビリティ
sat
PRO
2
520
Linuxのプロセススケジューラの負荷分散処理
sat
PRO
0
49
Linuxのプロセススケジューラの歴史 v0.01~v2.4.x
sat
PRO
0
53
Linuxのプロセススケジューラの歴史 v2.6.23~v4.18
sat
PRO
0
55
aslr.pdf
sat
PRO
0
18
わたしの愛する本たち
sat
PRO
1
300
実行ファイル
sat
PRO
0
34
Other Decks in Technology
See All in Technology
次期LTSに備えよ!AOS 6.1 HCI Core 編
smzksts
0
180
家の明るさ制御 / Brightness Control in My House
1024jp
0
120
5分で完全理解するGoのiota
uji
3
2.1k
Building smarter apps with machine learning, from magic to reality
picardparis
4
3.1k
AWS CLI入門_20220513
suzakiyoshito
0
3.9k
Research Paper Introduction #98 "NSDI 2022 recap"
cafenero_777
0
200
Puny to Powerful PostgreSQL Rails Apps
andyatkinson
PRO
0
340
[SRE NEXT 2022]ヤプリのSREにおけるセキュリティ強化の取り組みを公開する
mmochi23
1
590
How We Foster Reliability in Diversity
nari_ex
PRO
9
2.8k
街じゅうを"駅前化"する電動マイクロモビリティのシェアサービス「LUUP」のIoTとSRE
0gm
1
790
Embedded SRE at Mercari
tcnksm
0
850
ITエンジニアを取り巻く環境とキャリアパス / A career path for Japanese IT engineers
takatama
0
600
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
157
12k
Atom: Resistance is Futile
akmur
255
20k
Automating Front-end Workflow
addyosmani
1351
200k
Statistics for Hackers
jakevdp
781
210k
Debugging Ruby Performance
tmm1
65
10k
Producing Creativity
orderedlist
PRO
333
37k
Music & Morning Musume
bryan
35
4.1k
Rails Girls Zürich Keynote
gr2m
86
12k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
226
15k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
100
5.9k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
15
910
Creatively Recalculating Your Daily Design Routine
revolveconf
206
10k
Transcript
Linuxのプロセススケジューラの歴史 v2.6.0~v2.6.22 Jan. 29th, 2022 Satoru Takeuchi Twitter: satoru_takeuchi 1
はじめに • Linuxカーネル(以下カーネル)のプロセススケジューラの歴史を振り返る • 対象バージョン: 最初のリリースv2.6.0からv2.6.22まで • 用語 ◦ タスク:
カーネルのスケジューリング単位。プロセスあるいはスレッド ◦ LCPU: カーネルがCPUとして認識するもの(物理CPU or コア or スレッド) ◦ Current: LCPU上で現在動作中のタスク 2
V2.6: O(1)スケジューラ • コア部分のアルゴリズム総とっかえ ◦ 実行可能タスク数が nのときのスケジュール処理の計算量が O(1) ◦ 対話型タスクの優先動作
◦ LCPUごとのランキュー ◦ 負荷分散 ◦ CPU affinity ◦ カーネルレベルスレッド 3
スケジュール処理の計算量がO(1) • ランキュー長が伸びてもスケジュール処理の速度が変わらない ◦ ランキューはActiveキュー、inactiveキューの2つ ◦ Activeキューの先頭からスケジュール。タイムスライスが切れたら inactiveキューへ移動 ◦ Activeキューが空になったら
inactiveキューと切り替え 4
スケジューラの挙動: 初期状態 5 Runnable 10 Runnable 10 active expired t0
t1
activeキューの先頭タスクが動作 6 Runnable 10 Runnable 10 active expired t0 t1
t0がタイムスライスを使い果たす 7 Runnable 0 Runnable 10 active expired t0 t1
t0がexpiredキューに入る 8 Runnable 0 Runnable 10 active expired t0 t1
t1が動作 9 Runnable 0 Runnable 10 active expired t0 t1
t1がタイムスライスを使い果たす 10 Runnable 0 Runnable 0 active expired t0 t1
t1がexpiredキューの末尾に移動 11 Runnable 0 Runnable 0 active expired t0 t1
タイムスライスをチャージ 12 Runnable 10 Runnable 10 active expired t0 t1
activeキューとinactiveキューを入れ替え 13 Runnable 10 Runnable 10 expired active t0 t1
sleepから起床したタスクはactiveキュー末尾へ 14 Runnable 10 Runnable 10 inactive active t0 t1
Runnable 5 t2 おはよう
優先度別ランキュー 15 nice値20のランキュー nice値-19のランキュー nice値0のランキュー … … active inactive active
inactive active inactive … …
高優先度ランキューの先頭から順番にスケジュール 16 nice値20のランキュー nice値-19のランキュー nice値0のランキュー 1 2 … … active
inactive 3 4 active inactive 5 6 active inactive … …
全activeキューが空になると… 17 nice値20のランキュー nice値-19のランキュー nice値0のランキュー … … active inactive active
inactive active inactive … …
activeキューとinactiveキューをスイッチ 18 nice値20のランキュー nice値-19のランキュー nice値0のランキュー … … inactive active inactive
active inactive active … …
対話型タスクの優先動作 • 対話型タスク: bashやXなどの人間が直接やりとりするタスク • 課題 ◦ 実行可能タスク増加に伴い対話型タスク起床時のスケジュールが遅れる ◦ ユーザの体感レイテンシが長くなる
• 対策: ヒューリスティックを入れる ◦ 単位時間あたりにsleepしている率が高いプロセスを対話型タスクとみなす ◦ 対話型タスクへの優遇 ▪ タイムスライスが切れると expiredキューではなくactiveキューに移す ▪ 内部的にnice値を下げる: タイムスライスは変化しない ▪ その一方、ずっと実行可能なタスクは優先度を下げる (最大5) 19
LCPUごとのランキュー • 個々のLCPUのスケジュールが他のLCPUと競合しない 20 active inactive active inactive • 優先度別ランキューはスペースの都合上省略
LCPU0 LCPU1
LCPUごとのランキューにまつわる問題 • ランキュー長が偏る 21 LCPU0 LCPU1 ランキュー長=4 忙しいんですけど あっそ ランキュー長=0
負荷分散 • 負荷の高いLCPUから負荷の低いLCPUにタスクを移動 ◦ 負荷 ~= ランキュー長 ◦ のちに負荷はnice値やスケジューリングポリシーを考慮して重み付けするようになる •
動作契機 ◦ 新たにLCPUがアイドルになったとき ◦ 周期的に起動 22
ロードバランサ: 初期状態 • ランキュー長が偏る 23 LCPU0 LCPU1 ランキュー長=4 忙しいんですけど ランキュー長=0
バランス後 • ランキュー長が偏る 24 LCPU0 LCPU1 ランキュー長=2 ありがとう ランキュー長=2 しょうがねえなあ
移動
ロードバランサとNUMA • NUMAシステムの場合は2階層のバランス処理 1. NUMAノード間のバランス 2. ノード間LCPU間のバランス • のちにさらに階層が増えるがここでは割愛 25
ロードバランサの挙動: 初期状態 • 2ノード×2CPU(合計4LCPU)構成 26 t0 t1 t5 t4 t3
LCPU0 LCPU1 LCPU2 LCPU3 t2 node0 node1
一番busyなnodeと暇なnodeを見つける • 27 t0 t1 t5 t4 t3 LCPU0 LCPU1
LCPU2 LCPU3 t2 node0 node1 タスク数4 タスク数2
一番busyなnode内の一番忙しいLCPUを選ぶ • 28 t0 t1 t5 t4 t3 LCPU0 LCPU1
LCPU2 LCPU3 t2 node0 node1 タスク数3 タスク数1
一番暇なnode内の一番暇なLCPUを選ぶ • 29 t0 t1 t5 t4 t3 LCPU0 LCPU1
LCPU2 LCPU3 t2 node0 node1 タスク数0 タスク数2
一番busyなLCPUから一番暇なLCPUにタスクを移動 • 30 t0 t1 t5 t4 t3 LCPU0 LCPU1
LCPU2 LCPU3 t2 node0 node1 t2 移動
CPU affinity • タスクを動作させるLCPUの集合を決められる ◦ 用途: 全CPUで1つずつ動かしたいハートビート用タスクなど ◦ sched_setaffinity()システムコールやtasksetコマンドによって設定 31
T0 Affinity: 0, 1 T1 Affinity: 0 T2 Affinity: 1 LCPU0 LCPU1 × 移動可 〇 移動不可
豆知識: CentOS 3のひみつ • 2.4系カーネルを採用 32 2.4
魔改造カーネル • 実はO(1)スケジューラをバックポート済 33 2. 4 O(1)スケジューラ
魔改造カーネルの欠点 • Upstreamへの追従が大変すぎて死ぬ 1. upstreamの新バージョンが出る 2. 全パッチから必要なものを抽出 3. 必要なパッチをバックポート 4.
1に戻る • 最近はどこもupstream firstを謳っており、こういうのは減っている 34 じゃあの
V2.6.12: cpuset • タスクのグループに割り当てられるCPUのリストやメモリ量などを制限 • アプリやユーザごとの資源管理に利用 • /dev/cgroup以下ファイルによって操作 35 Cpuset0
動作可能LCPUリスト: 0, 1 使用可能メモリ量: 100MB Cpuset1 動作可能LCPUリスト: 2, 3 使用可能メモリ量: 200MB t0 t1 t2
O(1)スケジューラの諸問題 • ヒューリスティック多すぎでコーナーケースが山ほどある ◦ 例: 応答性向上機能のせいでシステムが応答しなくなる 1. スリープと起床を繰り返すタスクを大量に起動 2. 一部タスクが対話的とみなされて優先度が最高に
3. 2で述べたタスクがタイムスライスを使い切ると activeキューに 4. 他のタスクは全く動けない • 実行可能タスク数が多いとなかなかCPU時間が回ってこない • タイムスライスの粒度が荒くて細かい制御ができない ◦ 粒度を増やすにはタイマー割り込みの回数を増やす必要がある ◦ 細かくすると割り込み回数が上がってシステム全体の性能が下がる 36
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がいいよ
V2.6.23: CFSの勝利 • いったんは開発版カーネルにRSDLがマージされる • …が、最終的に安定版のv2.6.23にはCFSがマージされる 38 勝った 負けた
さらばCon Kolivas • Linuxカーネル開発引退表明 • ホームページに日本語の謎ダイイングメッセージを残す 39 さようなら、いままで魚をありがとう
まとめ 1. O(1)のスケジューラの導入 2. 負荷分散処理の改善 3. 対話型タスクの特別扱いとその課題 4. 次世代スケジューラの覇権争い 40