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.23~v4.18
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Satoru Takeuchi
PRO
January 29, 2022
Technology
550
0
Share
Linuxのプロセススケジューラの歴史 v2.6.23~v4.18
以下動画のテキストです。
https://youtu.be/hrKENEC7Gsg
Satoru Takeuchi
PRO
January 29, 2022
More Decks by Satoru Takeuchi
See All by Satoru Takeuchi
システム強制終了時にファイルシステムの整合性を保つ~ コピーオンライト編 ~
sat
PRO
0
51
システム強制終了時に ファイルシステムの整合性を保つ ~ ジャーナリング編 ~
sat
PRO
1
57
ファイルシステムの整合性を回復するfsck
sat
PRO
1
58
小学校5,6年生向けキャリア教育 大人になるまでの道
sat
PRO
8
4.8k
ファイルシステムの不整合
sat
PRO
2
150
書籍執筆での生成AIの活用
sat
PRO
2
500
ChatGPTに従って体調管理2026
sat
PRO
0
180
eBPF
sat
PRO
1
160
waruiBPF
sat
PRO
0
140
Other Decks in Technology
See All in Technology
DevOps Agentで始めるAWS運用 〜フロンティアエージェントが変える運用の現場〜
nyankotaro
1
130
正解のないAIプロダクトをどう導くか?dodaが挑む、ユーザーの『本音』を構造化する評価設計と検証のリアル
techtekt
PRO
0
170
探して_入れて_作って_使う_Agent_Skills___LT.pdf
peintangos
2
160
TypeScript Compiler APIとPHP-Parserを活用し、TypeScriptとPHPで型を共有する
shuta13
0
350
生成 AI × MCP で切り拓く次世代 SRE!自律型運用への挑戦と開発者体験の進化
_awache
0
140
速さだけじゃない! VoidZero ツールが移行先に選ばれる理由
mizdra
PRO
6
740
Oracle AI Database@AWS:サービス概要のご紹介
oracle4engineer
PRO
4
2.8k
Unlocking the Apps
pimterry
0
200
サイバーセキュリティ概論 / Introduction to Cybersecurity
ks91
PRO
0
140
関西に縁あるMicrosoft MVPsが語るCopilotの未来
kasada
0
1k
ITエンジニアを取り巻く環境とキャリアパス / A career path for Japanese IT engineers
takatama
4
1.8k
JEP 522 Deep Dive - G1 GC同期コスト削減によるスループット向上を徹底検証&解説
tabatad
1
740
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
250
1.3M
Designing Experiences People Love
moore
143
24k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
1
340
Marketing to machines
jonoalderson
1
5.3k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
180
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
480
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
250
Darren the Foodie - Storyboard
khoart
PRO
3
3.4k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
590
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
11k
Statistics for Hackers
jakevdp
799
230k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
200
Transcript
Linuxのプロセススケジューラの歴史 v2.6.23~v4.18 Jan. 29th, 2022 Satoru Takeuchi Twitter: satoru_takeuchi 1
はじめに • Linuxカーネル(以下カーネル)のプロセススケジューラの歴史を振り返る • 対象バージョン: 最初のリリースv2.6.23からv4.18まで • 用語 ◦ タスク:
カーネルのスケジューリング単位。プロセスあるいはスレッド ◦ LCPU: カーネルがCPUとして認識するもの(物理CPU or コア or スレッド) ◦ Current: LCPU上で現在動作中のタスク 2
Completely Fair Scheduler (CFS) • レイテンシターゲットによるスケジューリング • 細かいタイムスライス粒度 • プラガブルなスケジューリングアルゴリズム
3
レイテンシターゲットによるスケジューリング • ランキューはvruntimeと呼ばれる仮想的なキー(後述)とした赤黒木 ◦ スケジューリング処理の計算量は O(log(n)) ◦ active/inactiveキュー、および優先度別ランキューは廃止 • 各タスクはレイテンシターゲットと呼ばれる期間に一度CPU時間を得られる
◦ レイテンシターゲットは数 ms~数十ms。システムのLCPU数やバージョンによって変わる ◦ タイムスライス = レイテンシターゲット ()/runnableタスク数 4
LCPU上で動くタスク 5 タスク数2 タスク数3 タスク数4 時間 t0 t1 t0 t1
t0 t1 t2 t0 t1 t2 t0 t1 t2 t3 t0 t1 t2 t3 レイテンシターゲット レイテンシターゲット
スケジューラの挙動: 初期状態 • 仮定 ◦ レイテンシターゲット : 10 [ms] •
タイムスライス=10/(runnableタスク数=3) [ms] 6 0 0 0 t0 t1 t2 vruntime(簡単のため簡略化している ) LCPU
ランキュー先頭のタスクをcurrentに 7 0 0 t1 t2 LCPU 0 t0
タイムスライス切れまで動かす • 10/3 [ms]動くとvruntimeが1.0増えるよう計算 8 0 0 t1 t2 LCPU
1.0 t0
currentをランキューに再挿入 9 0 0 t1 t2 LCPU 1.0 t0
vruntime=1.0になるまで繰り返し。これが続く 10 1.0 1.0 t0 t1 LCPU 1.0 t2
sleep中のタスクが起床したときは? 11 1.0 1.0 t1 t2 LCPU t3 1.5 t0
おはよう
vruntimeをrunnableタスク内最小値にしてランキューに挿入 • vruntime=15のタスクの残りタイムスライス ◦ (2.0-1.5)*(10/3)=1.67 [ms] → (2.0-1.5)*(10/4) = 1.25
[ms] • vruntime=10のタスクの残りタイムスライス ◦ (2.0-1.0)*(10/3)=3.3 [ms] → (2.0-1.0)*(10/4) = 2.5 [ms] 12 1.0 1.0 t1 t2 LCPU 1.0 t3 1.5 t0
nice値の扱い • Niceの変化によってタイムスライスの比率が変わる ◦ nice値が低い(高優先度): 比率が上がる ◦ nice値が低い(低優先度): 比率が下がる 13
T0 0 T1 -1 T0 0 T1 0 T0 0 T1 1 時間 T0 0 T1 0 nice値 T0のnice値 > t1のnice値 T0のnice値 == t1のnice値 T0のnice値 < t1のnice値 T0 0 T1 -1 T0 0 T1 1
プラガブルなスケジューラ • アルゴリズム別にスケジューリングクラスという概念を導入 ◦ 効果: 後からスケジューラを追加するのが楽 & コードの見通しが良い ◦ クラスごとにコールバック関数のセットを用意
▪ 次のcurrentを選ぶ関数、タスクの sleep時に呼ぶ関数、起床時に呼ぶ関数、など • 高優先度のクラスに属する実行可能タスクは低優先度のクラスに属するタスクより 優先動作 ◦ スケジューリングクラス (優先度順) ▪ rt_shed_class: リアルタイムタスク。ポリシーは SCHED_{FIFO,RR} ▪ fair_sched_class: 通常のプロセス。ポリシーは SCHED_OTHER 14
細かいタイムスライス粒度 • O(1)まで ◦ レガシーなインターバルタイマーを使用 : 定期的に割り込みが発生し続ける ◦ ms単位が限度 •
CFS ◦ ワンショット高精度タイマー : タイムスライスが切れる時に割り込みを発生させる ◦ ns単位の制御が可能 15
V2.6.24: fair group scheduling • Cpu cgroup 1. グループ間でCPUを均等配分 2.
グループ内でさらに均等配分 • Cpu cgroupのcpu.sharesパラメタによって重み付けも可能 • ネストも可能 16
LCPU上で動くタスク 17 時間 t0 t1 t2 t0 t1 t2 cgroupなし
Cgroupあり グループA: t0, t1 グループB: t2 t0 t1 t2 t0 t1 t2 1 1/3 1/3 1/3 1 1/4 1/4 1/2 1/2
LCPU上で動くタスク: share変更あり 18 時間 t0 t1 t0 t1 Cgroupあり グループA:
t0 share: 1 グループB: t1 share: 1 Cgroupあり グループA: t0 Share: 1 グループB: t1 Share: 2 1 1/2 1/2 t0 t1 1 1/3 2/3 t0 t1
Use case: ユーザ間でCPU資源を均等配分 • 例: ユーザAがt0, ユーザBがt1-t3を動かしているとする 19 Fair group
scheduling不使用 ユーザごとにグループ作成 時間 t0 t1 t2 t3 時間 t0 t1 t2 t3 タスク同士が公平 ユーザ同士は不公平 ユーザ同士が公平
V2.6.24: cpuset cgroup • Cpusetをcgroupに統合したもの • cpusetを/dev/cpusetだけでなく/sys/fs/cgroupから操作可能に 20
リアルタイムタスクが止まらない問題 • リアルタイムタスクが暴走すると通常のタスクが一切動けない • コアが1つしかないとシステムがハング • 例: ランキュー上にいるタスク ◦ T0:
リアルタイムタスク(SCHED_FIFO)。CPUを自発的に明け渡さず動き続ける ◦ T1: 通常のタスク(SCHED_OTHER)。t0暴走中に起床 21 t0 時間 t1は一切動けない t1起床
V2.6.25: Realtime group scheduling • リアルタイムタスクは所定の期間内に一定の時間しか動作できない ◦ 所定の期間: sysctlのkernel.sched_rt_period_us(デフォルトは1000000[us]) ◦
一定の時間: sysctlのkernel.sched_rt_runtime_us(デフォルトは950000[us]) • 空いた時間に通常のタスクが動ける • Cpu cgroupのcpu.rt_{period,runtime}によって入れ子構造にできる 22 t0 時間 t1は1秒間に50msだけは動ける t1 t0 t1 t1起床
重要なカーネルスレッドが動けない問題 • 優先度最高のリアルタイムタスクがCPUを使い続けるとカーネルの重要なタスクが 動けなくなる ◦ 例: CPU hotplug時のシステムの機能をほぼ止める stop_machineという処理 •
原因: カーネルタスクの最高優先度 == ユーザタスクの最高優先度 23
V2.6.37: Stop scheduling class • 全てのユーザプロセスに優先して動くカーネル専用スケジューリングクラス • スケジューリングクラス(優先度順) 1. (new)
Stop_sched_class 2. Rt_sched_class 3. fair_sched_class 24
スケジューラの挙動: stop scheduling classなし • 例: ランキュー上のタスク • T0: ユーザのタスク。暴走していて
CPUを自発的に手放さない ◦ 優先度最大(99)のリアルタイムタスク • T1: カーネルの重要なタスク。 t0暴走中に起床 ◦ 優先度最大(99)のリアルタイムタスク 25 t0 時間 t1は一切動けない t1起床
スケジューラの挙動: stop scheduling classあり • 例: ランキュー上のタスク • T0: ユーザのタスク。暴走していて
CPUを自発的に手放さない ◦ 優先度最大(99)のリアルタイムタスク • T1: カーネルの重要なタスク。 t0暴走中に起床 ◦ Stop scheduling classのタスク 26 t0 時間 t1起床 t1 t0 T1 sleep or exit
Con Kolivas氏、再び • Brain Fuck Scheduler(BFS)というスケジューラを引っ提げてLKMLに帰還 • 「mainlineに入れるつもりは無い」と最初から宣言 27 待たせたな
しばらくしたらフェードアウト 28 じゃあの
V2.6.38: autogroup • システム高負荷時におけるデスクトップ環境の応答性向上機能 ◦ 通称ミラクルパッチ • アイデア ◦ セッションごとにタスクを自動的にグループ分け
◦ グループごとに平等に CPU資源を与える • Linus氏が「小さい効果で効果が大きい」と大絶賛。パッチ投稿後速攻マージ • しかしこれも一部ケースを救うだけ ◦ 例: デスクトップアプリを動かす横でカーネルビルドをぶん回す非常に一般的なワークロード 29
Fair group schedulingの課題: 上限設定ができない • 例: 2ユーザA, B同居のマルチテナントシステム ◦ やりたいこと:
個々のユーザにCPU資源を”最大”1/2与えたい ▪ ユーザ間の不平等、過剰なサービスの提供を避けたい ◦ Fair group schedulingにできること: ユーザごとにグループ作成 30 時間 Aだけがタスクを動かしている状態 (あるべき姿) Aのタスク Aだけがタスクを動かしている状態 (現実) Aのタスク idle Aのタスク idle
V3.2: CFS bandwidth controller • あるcpu cgroupが所定期間内に動ける時間を制限 ◦ cpu.Cfs_period: 期間([us]単位)
◦ Cpu.cfs_quota: 動ける時間([us]単位) • ネストも可能 • コンテナやVMのリソース制限に使われる 31
スケジューラの挙動 • レイテンシターゲットは10ms • グループAのcpu.cfs_period=10ms, cpu.cfs_runtime=5ms 32 時間 t0 t1
t0 t0 t1 bwc不使用 t1がsleep t1が起床 t0 t1 t0 idle t0 t1 Bwc使用 T0はグループAに所属 t1がsleep t1が起床
V3.14: Deadlineスケジューラ • 所定の期間中にどれだけのCPU時間を使うかを設定できる • rootのみ使える • スケジューリングクラス 1. Stop_sched_class
2. (new) Deadline_sched_class 3. Rt_sched_class 4. Fair_sched_class • sched_setscheduler() or sched_setparam()で以下3つのパラメタを与える 1. Period: タスクはperiodで示された期間中に最大 1度動作 2. Runtime: タスクが一度起床してから sleepするまでの計算所要時間 3. deadline: タスクが起床してから計算を終了しなくてはならない期間 33
v4.18 • マイナーチェンジ中心、機能的にはあんまり変わってない(はず) 34
まとめ • CFSの導入 • Cgroupによるfair share scheduler, bandwidth controllerの導入 •
Deadline schedulerの導入 35