Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Linuxのプロセススケジューラの歴史 v2.6.0~v2.6.22
Search
Satoru Takeuchi
PRO
January 29, 2022
Technology
0
280
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
Linux環境のCPU上で10ミリ秒間に起こること
sat
PRO
3
73
HDDへのアクセス速度は位置によって変わる!??
sat
PRO
4
33
ボリュームマネージャLVM
sat
PRO
2
74
Best Practices of Production-Grade Rook/Ceph Cluster
sat
PRO
1
1.7k
OSSへの貢献をはじめたきっかけ、貢献で得たもの、やりたい人へのアドバイス(改)
sat
PRO
4
120
device mapperによるディスクI/O障害のエミュレーション 既存ターゲット編
sat
PRO
0
100
分散ストレージCephのデータ破壊検知修復機能は本当に動作するのか
sat
PRO
0
42
ディスクI/O障害のエミュレーション カーネルモジュール自作編
sat
PRO
0
39
分散ストレージはすごいぞ
sat
PRO
2
2.5k
Other Decks in Technology
See All in Technology
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
pospome
11
3k
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
7
100k
今さら聞けない!? AWSの生成AIサービス Amazon Bedrock入門!
minorun365
PRO
11
2.2k
実務への応用例から考える 変更に強いオブジェクト指向設計 / 20240324-ooc2024
bengo4com
7
5k
Azureコストは水道代/The_47th_Tokyo_Jazug
aeonpeople
3
350
複数の LLM モデルを扱う上で直面した辛みまとめ
kazuyaseki
1
230
検証からプロダクトへ: シームレスなLLM開発の ためのしくみ作り
nunukim
1
150
戦略的DDDを実践するための跳躍力 / OOC 2024
pictiny
6
3.9k
Autify Company Deck
autifyhq
1
30k
現実世界の事象から学ぶSOLID原則
h0r15h0
24
10k
AWS アーキテクチャクイズ
yuu26
2
700
単回帰分析について数式を追いながら実装してみた
kentaitakura
0
500
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
50
8.6k
For a Future-Friendly Web
brad_frost
170
8.9k
A better future with KSS
kneath
230
16k
Teambox: Starting and Learning
jrom
126
8.4k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
272
12k
GitHub's CSS Performance
jonrohan
1023
450k
Facilitating Awesome Meetings
lara
39
5.5k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
219
21k
The MySQL Ecosystem @ GitHub 2015
samlambert
242
12k
Bootstrapping a Software Product
garrettdimon
PRO
302
110k
Learning to Love Humans: Emotional Interface Design
aarron
266
39k
Designing the Hi-DPI Web
ddemaree
275
33k
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