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
580
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Linuxのプロセススケジューラの歴史 v0.01~v2.4.x
以下動画のテキストです。
https://youtu.be/iPlcotf6It4
Satoru Takeuchi
PRO
January 29, 2022
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
Rook: Intro and Deep Dive with Ceph
sat
PRO
1
59
Machine Check Exception
sat
PRO
2
54
バイナリダンプの模様を読む
sat
PRO
0
74
cpコマンドはディスク上でデータを コピーしないことがある
sat
PRO
3
62
114-ファイルのshallow_copy.pdf
sat
PRO
2
45
113-Btrfsのスナップショット.pdf
sat
PRO
0
28
システム強制終了時にファイルシステムの整合性を保つ~ コピーオンライト編 ~
sat
PRO
0
66
システム強制終了時に ファイルシステムの整合性を保つ ~ ジャーナリング編 ~
sat
PRO
2
72
ファイルシステムの整合性を回復するfsck
sat
PRO
1
78
Other Decks in Technology
See All in Technology
システム思考で問題に対処する
yussak
0
350
DDDのエッセンスを取り入れたAIでの開発
ak2ie
0
140
FPGAが実現する遠方宇宙の高空間分解能天体撮影 -大型地上望遠鏡の視力を補正する「補償光学」とは?-
komei_mt
0
560
つくって納得、つかって実感! 大規模言語モデルことはじめ ver2.0
recruitengineers
PRO
5
2k
Android skills に学ぶ
kokiko
0
120
Model Studio CLI × Token Plan
maigo999
0
190
SO-101×VLAによる3色キューブのピック&プレース
abeja
0
220
20分でわかるセキュアAPI
nwiizo
2
310
AIで変わるエンジニアの働き方(仮)
naoinaoi
0
130
Bits AI を制するものは Datadog を制す / The player that controls Bits AI, controls Datadog
kaminashi
0
140
案件に一番詳しいAIを Amazon Bedrock AgentCore で作る ― 知見が知見を生むチームへ / Compounding Knowledge with AgentCore
yusukeshimizu
1
150
JavaScript 研修 (2026)
recruitengineers
PRO
2
650
Featured
See All Featured
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.9k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
350
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Why Our Code Smells
bkeepers
PRO
340
58k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
420
Are puppies a ranking factor?
jonoalderson
2
3.8k
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.4k
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
300
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
220
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
260
Balancing Empowerment & Direction
lara
6
1.2k
The Cult of Friendly URLs
andyhume
79
7k
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