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のプロセススケジューラの歴史 v0.01~v2.4.x
Search
Satoru Takeuchi
PRO
January 29, 2022
Technology
0
430
Linuxのプロセススケジューラの歴史 v0.01~v2.4.x
以下動画のテキストです。
https://youtu.be/iPlcotf6It4
Satoru Takeuchi
PRO
January 29, 2022
Tweet
Share
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
利きプロセススケジューラ
sat
PRO
5
2.9k
俺とVSCode Python Debugger Extension
sat
PRO
1
180
コード再利用のしくみ ライブラリ
sat
PRO
3
49
AWKへの愛を語る
sat
PRO
3
520
syncコマンドのデータ同期 完了待ちやエラー検出
sat
PRO
0
64
動作中のLinux環境の全メモリを見る
sat
PRO
1
96
Linuxの時間を10秒止める
sat
PRO
2
210
プロセスへのメモリ割り当て4 - 実際に使うときにメモリを獲得するデマンドページング(実践編)
sat
PRO
1
120
プロセスへのメモリ割り当て(3) 実際に使うときにメモリを獲得するデマンドページング
sat
PRO
1
73
Other Decks in Technology
See All in Technology
rootlessコンテナのすゝめ - 研究室サーバーでもできる安全なコンテナ管理
kitsuya0828
3
390
マルチモーダル / AI Agent / LLMOps 3つの技術トレンドで理解するLLMの今後の展望
hirosatogamo
37
13k
個人でもIAM Identity Centerを使おう!(アクセス管理編)
ryder472
4
240
SDNという名のデータプレーンプログラミングの歴史
ebiken
PRO
2
130
OCI Security サービス 概要
oracle4engineer
PRO
0
6.5k
BLADE: An Attempt to Automate Penetration Testing Using Autonomous AI Agents
bbrbbq
0
330
TypeScriptの次なる大進化なるか!? 条件型を返り値とする関数の型推論
uhyo
2
1.7k
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
200
"とにかくやってみる"で始めるAWS Security Hub
maimyyym
2
100
[CV勉強会@関東 ECCV2024 読み会] オンラインマッピング x トラッキング MapTracker: Tracking with Strided Memory Fusion for Consistent Vector HD Mapping (Chen+, ECCV24)
abemii
0
230
Adopting Jetpack Compose in Your Existing Project - GDG DevFest Bangkok 2024
akexorcist
0
120
飲食店データの分析事例とそれを支えるデータ基盤
kimujun
0
210
Featured
See All Featured
Building an army of robots
kneath
302
43k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
KATA
mclloyd
29
14k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Building Your Own Lightsaber
phodgson
103
6.1k
Bash Introduction
62gerente
608
210k
Become a Pro
speakerdeck
PRO
25
5k
Writing Fast Ruby
sferik
627
61k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
44
2.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
A better future with KSS
kneath
238
17k
Transcript
Linuxのプロセススケジューラの歴史 v0.01~v2.4.x Jan. 29th, 2022 Satoru Takeuchi Twitter: satoru_takeuchi 1
はじめに • Linuxカーネル(以下カーネル)のプロセススケジューラの歴史を振り返る • 対象バージョン: 最初のリリースv0.01からv2.4.xまで • 用語 ◦ タスク:
カーネルのスケジューリング単位。プロセスあるいはスレッド ◦ LCPU: カーネルがCPUとして認識するもの(物理CPU or コア or スレッド) ◦ Current: LCPU上で現在動作中のタスク 2
V0.01: 概要 • 超絶シンプルなラウンドロビンスケジューリング ◦ コア部分は20行弱 • タスクを管理する配列がそのままランキュー ◦ 長さは64:
つまりタスクは最大でも 64 ◦ 空要素にはnilが入る • タイムスライスは固定150[ms] ◦ インターバルタイマーの 1tickは10[ms] ◦ のちにタイムスライスはコロコロ変わるが、あまり重要じゃないので省略 • currentのタイムスライス切れ or 全タスクがsleepならスケジューラを呼ぶ 3
V0.01: スケジューリングアルゴリズム • ランキューを全走査して残りタイムスライスが最大のものを次に動かす • 該当者がいなければ全タスクのタイムスライスをリセット ◦ タイムスライスが切れているプロセスには 150[ms]与える ◦
スリープ中のタスクには残りタイムスライス /2をボーナスとして与える ▪ 寝起きを繰り返すbashなどを起床時に優先的に動作させる仕組み (多分) 4
スケジューラの挙動: 初期状態 5 runnable 10 runnable 15 nil runnable 5
ランキュー (タスク管理配列) sleep 12 タイムスライス タスク未割当 タスクの状態 t0 t1 t2 t3 t4
スケジューリング 6 runnable 10 runnable 15 nil runnable 5 ランキュー
(タスク管理配列) sleep 12 ランキュー全走査 runnableの中でタイムスライスが最大のものを選ぶ t0 t1 t2 t3 t4
t1がタイムスライス切れ 7 runnable 10 runnable 0 nil runnable 5 ランキュー
(タスク管理配列) sleep 12 t0 t1 t2 t3 t4
次のスケジューリング 8 runnable 10 runnable 0 nil runnable 5 ランキュー
(タスク管理配列) sleep 12 ランキュー全走査 runnableの中でタイムスライスが最大のものを選ぶ • タイムスライスが同じタスクが複数いれば最初に見つかったものを選択 t0 t1 t2 t3 t4
全員がタイムスライス切れ or sleep 9 runnable 0 runnable 0 nil runnable
0 ランキュー (タスク管理配列) sleep 12 t0 t1 t2 t3 t4
タイムスライスをリチャージ 10 runnable 15 runnable 15 nil runnable 15 ランキュー
(タスク管理配列) sleep 21 • スリープ中のタスクには残り ”タイムスライス/2”をボーナスとして与える t0 t1 t2 t3 t4
sleepから起床したタスクはrunnableになるだけ 11 runnable 15 runnable 15 nil runnable 15 ランキュー
(タスク管理配列) runnable 21 t0 t1 t2 t3 t4 おはよう • Preemption? そんなものは無い
V0.01: その他 • Nice値 ◦ 変更するとタイムスライスが増減 ◦ rootでなくてもマイナス値を設定可能 ◦ 任意の値を設定可能
▪ 例: nice値-10,000 => タイムスライスは100,150[ms] ◦ 絶対値を指定できない : setpriority()システムコールは無い • タスク == プロセス。カーネル内でスレッドを扱えない 12
v1.0 • Preemptionの導入 ◦ 条件: sleepから起床したタスクのタイムスライス > currentのタイムスライス • Nice値の扱いがまともになる
◦ Rootでないとマイナス値を設定できなくなる ◦ nice値は-19~20の間のみ意味を持つようになる ◦ Nice値の絶対値を指定可能に : {set,get}priority()システムコールが追加 13
v2.0 • ランキューのデータ構造がリストに • SMP対応 • リアルタイムポリシーの追加 14
ランキューデータ構造がリストに • スケジューリングアルゴリズム ◦ ランキューからタイムスライスが最大のタスクをとってくる • タイムスライスを使い果たすとランキュー末尾に挿入 • 生成直後&sleep起床時のタスクもランキュー末尾に挿入 •
ランキューへのタスク挿入時にソートしない ◦ スケジューリング処理の計算量は O(n): nはrunnableタスクの数 15
スケジューラの挙動: 初期状態 16 Runnable 10 Runnable 15 Runnable 5 t0
t1 t2
スケジューリング 17 Runnable 10 Runnable 15 Runnable 5 ランキュー全走査 runnableの中でタイムスライスが最大のものを選ぶ
t0 t1 t2
タイムスライス切れ 18 Runnable 10 Runnable 0 Runnable 5 t0 t1
t2
タイムスライス切れタスクはランキュー末尾へ 19 Runnable 10 Runnable 5 Runnable 0 • この後の流れはv1.0以前のものと同じ
t0 t2 t1
sleepから起床したタスクはランキュー末尾へ 20 Runnable 10 Runnable 5 Runnable 0 Runnable 15
t0 t2 t1 t3 おはよう • Preemption発生 ◦ T3のタイムスライス > current(t0)のタイムスライス
V2.0: SMP対応 • ランキューはグローバルなもの1本 • sleepからの起床時には直前に動作したLCPU上で動作しやすくなっている ◦ 前回動作時の状態がキャッシュメモリに残ってる可能性が高いという推測 (多分) •
ロードバランサは無い(必要もない) 21 LCPU0 LCPU1 Runnable 10 Runnable 15 Runnable 5 共有 t0 t1 t2
リアルタイムポリシーの追加 • タスクをリアルタイムタスクにできる ◦ 通常のタスク(SCHED_OTHERポリシー)より常に優先的に動作可能 ◦ 用途: ハートビート処理など (1秒ごとに起動して通信してすぐ寝る、など )
• 二種類ある ◦ SCHED_FIFOポリシー: タイムスライスなし。ここではこちらのみ扱う ◦ SCHED_RRポリシー: タイムスライスあり • sched_setscheduler()システムコールやchrtコマンドによって設定 ◦ rootのみ設定可能 22
スケジューラの挙動: 初期状態 23 Runnable OTHER 10 Runnable FIFO -- Runnable
FIFO -- t0 t1 t2
スケジューリング 24 Runnable OTHER 10 Runnable FIFO -- Runnable FIFO
-- • ランキュー全走査 • リアルタイムタスクは「常に」通常のタスクより優先動作 t0 t1 t2
リアルタイムタスクがcurrentになると… 25 Runnable OTHER 10 Runnable FIFO -- Runnable FIFO
-- sleepするかexitするまでSCHED_OTHERがいくら待とうがずっと動作 t0 t1 t2
v2.2とv2.4 • 大して変化なし ◦ タイムスライスの計算方法が変わったくらい 26
まとめ • 初期におけるLinuxのプロセススケジューラの実装は極めてシンプルだった • 徐々に機能が増えてきた ◦ プリエンプション ◦ リアルタイムスケジューリング ◦
SMP対応 27