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
540
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
書籍執筆での生成AIの活用
sat
PRO
1
300
ChatGPTに従って体調管理2026
sat
PRO
0
150
eBPF
sat
PRO
1
110
waruiBPF
sat
PRO
0
110
eBPFとwaruiBPF
sat
PRO
5
3.8k
Pythonのコードの気になる行でスタックトレースを出す
sat
PRO
1
100
ソースコードを読むときの思考プロセスの例 ~markdownのレンダリング方法を知りたかった2 markdownパッケージ~
sat
PRO
0
200
様々なファイルシステム
sat
PRO
0
340
ソースを読む時の思考プロセスの例-MkDocs
sat
PRO
1
430
Other Decks in Technology
See All in Technology
生成AIを活用した音声文字起こしシステムの2つの構築パターンについて
miu_crescent
PRO
3
220
AI駆動開発を事業のコアに置く
tasukuonizawa
1
360
登壇駆動学習のすすめ — CfPのネタの見つけ方と書くときに意識していること
bicstone
3
130
Embedded SREの終わりを設計する 「なんとなく」から計画的な自立支援へ
sansantech
PRO
3
2.6k
Red Hat OpenStack Services on OpenShift
tamemiya
0
130
Codex 5.3 と Opus 4.6 にコーポレートサイトを作らせてみた / Codex 5.3 vs Opus 4.6
ama_ch
0
200
SchooでVue.js/Nuxtを技術選定している理由
yamanoku
3
200
Oracle Cloud Observability and Management Platform - OCI 運用監視サービス概要 -
oracle4engineer
PRO
2
14k
[JAWS-UG彩の国埼玉#6]混乱しました。AWS MCP ServersとAWS MCP Serverの違いを5分で解説
sh_fk2
0
100
CDKで始めるTypeScript開発のススメ
tsukuboshi
1
550
usermode linux without MMU - fosdem2026 kernel devroom
thehajime
0
240
生成AIと余白 〜開発スピードが向上した今、何に向き合う?〜
kakehashi
PRO
0
150
Featured
See All Featured
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
330
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
120
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
0
160
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
130
The Language of Interfaces
destraynor
162
26k
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
110
How to build a perfect <img>
jonoalderson
1
4.9k
Navigating Team Friction
lara
192
16k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.7k
Skip the Path - Find Your Career Trail
mkilby
0
59
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
60
42k
Being A Developer After 40
akosma
91
590k
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