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
Xenのスケジューラがぜんぜんわからん
Search
Keisuke Nishimura
November 20, 2021
Programming
0
1.1k
Xenのスケジューラがぜんぜんわからん
Kernel/VM探検隊online part4 発表資料
Keisuke Nishimura
November 20, 2021
Tweet
Share
More Decks by Keisuke Nishimura
See All by Keisuke Nishimura
eBPFを使ったオレオレカーネル拡張入門
mu_mu_mu
1
810
C言語プログラムの構造とほんの少し解釈
mu_mu_mu
3
1.5k
Intel MPK入門
mu_mu_mu
0
560
Other Decks in Programming
See All in Programming
A Journey of Contribution and Collaboration in Open Source
ivargrimstad
0
1k
色々なIaCツールを実際に触って比較してみる
iriikeita
0
330
Functional Event Sourcing using Sekiban
tomohisa
0
100
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
120
PHP でアセンブリ言語のように書く技術
memory1994
PRO
1
170
cmp.Or に感動した
otakakot
3
210
Jakarta EE meets AI
ivargrimstad
0
620
2024/11/8 関西Kaggler会 2024 #3 / Kaggle Kernel で Gemma 2 × vLLM を動かす。
kohecchi
5
940
レガシーシステムにどう立ち向かうか 複雑さと理想と現実/vs-legacy
suzukihoge
14
2.3k
カンファレンスの「アレ」Webでなんとかしませんか? / Conference “thing” Why don't you do something about it on the Web?
dero1to
1
110
CSC509 Lecture 11
javiergs
PRO
0
180
[Do iOS '24] Ship your app on a Friday...and enjoy your weekend!
polpielladev
0
110
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Code Review Best Practice
trishagee
64
17k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
109
49k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
Statistics for Hackers
jakevdp
796
220k
How GitHub (no longer) Works
holman
310
140k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Building Your Own Lightsaber
phodgson
103
6.1k
Transcript
Xenのスケジューラが ぜんぜん わからん 西村 啓佑 / mumumu (@mumumu_vm ) Kernel/VM探検隊online
part4
Xenのアーキテクチャ DomU Dom0 DomU vCPU vCPU vCPU vCPU vCPU vCPU
pCPU pCPU pCPU NIC GPU Xen (VMM) Domain (VM) スケジューラ VM間通信機構 ・・・ ・・・ vCPUをpCPUに 割り当てる 2
vCPUスケジューリング • 目的は計算資源の再配分(OSスケジューラと同じ) • OSのスケジューリングとの違い • スケジューリング単位(VM v.s. Process) •
実際に動作するApp.に関する情報の粒度 • VMM-App.間にOSが挟まるDouble-Scheduling … • OSからみると,CPUが常に使えるとは限らない. (参考) 本来のOSはCPUは常に使えることが前提 • 例:IO発生時すぐにCPUに割り込みが来る想定 • 例:IPC発生時すべてのコアが動作している想定 3
Xen のスケジューラ • Credit スケジューラ • Credit2 スケジューラ • SEDFスケジューラ
• RTDSスケジューラ • BVTスケジューラ … ←このLTの対象 (汎用,非RT系) 4
Credit スケジューラ • 元デフォルトスケジューラ: 3.0~4.11 (2005-2018) • 固定タイムスライスでProportional Share(PS) •
タイムスライスはデフォで30ms固定 (例外あり:tickle, IO) • PS: 各VM(vCPU)はWeight(優先度)に比例した時間割当て • Credit = Weightに応じ配分された実行時間 • 使い果たしたVM (credit <= 0) OVER • 残っているVM (credit > 0) UNDER • UNDERのvCPUをRRで順にスケジュール 該当コード: xen/xen/common/sched/credit.c Creditの値に非依存 (「0以上か」が重要) 5
Credit スケジューラ 基本アルゴリズム 全てのvCPUに対して Weightに応じたCreditを配布(加算) Creditが正のvCPUを選んで実行 実行時間分のCreditを消費 Creditが正の vCPUが存在 定期実行
TS(固定)時間実行 6
Credit スケジューラ IOのLatencyを削減の工夫: UNDERなVMへのevent(IO)が発生したら, 一時的に最高優先度(BOOST)でvCPUを実行 図の引用元: F. Zhou, M. Goel,
P. Desnoyers, and R. Sundaram. Scheduler vulnerabilities and attacks in cloud computing. arXiv:1103.0759v1 [cs.DC] 7
実験:レイテンシ計測 8 目的:(1)BOOSTの影響を定量化し,(2)あるVMが別 のVMのIOレイテンシに与える影響を調査. 方法:バックグラウンドで動作するVMで全体に 負荷をかけつつ,別VM間のping RTT計測 • 負荷1:iperfで別マシンと通信するNW-boundなタスク •
負荷2:yes > /dev/null を実行するCPU-boundなタスク 補足1: VM間通信はIOではないが,VMから見るとIOとほとんど同じ. 外乱が少ないメリットがある. 補足2: 誤差を減らすため,pingはRTタスクで実行,DVFSは無効化
結果:レイテンシ計測 0 5 10 15 20 25 30 35 no
BG w/ CPU BG w/ NW BG ping RTT (msec) mean max BOOSTのおかげで レイテンシ小 Tail Latencyが最悪 (×60 ~ ) Creditスケジューラ(パラメタはデフォルト) 9
Creditスケジューラ 問題点:BOOSTしたvCPU間の調停無し (同マシンに複数のIO boundなVMが存在する場合等) • Tail Latencyの大幅な悪化として観測 • BOOSTで割り込んだたくさんのvCPUが,OVERにならな い程度に長い時間の処理を続けるのが原因
• 固定のデフォルトタイムスライス(TS)が長すぎるのが元凶 • 短いタイムスライス は相対的にContext Switchコスト大 解決策(1) 短いTS (現代のCPUなら無難だが,限界あり) 解決策(2) BGのVMにCapを導入 (×Work Conservation) 10
Credit スケジューラ Capと Work Conservation • Cap: VM(vCPU)の1pCPUに対する実行可能時間 (割合)の上限(%単位表記) •
例: 4pCPU上であるVM(3vCPU)が, cap値 200[%] で動作 = 最大で全体の50%(200/(4*100))のpCPUを使用可能 (cap無しの場合,最大で全体の75% (3/4)のCPU利用可能) • Work Conservation(WC): Idleな(p)CPUがあるときほか のCPUで実行待ちのタスク(vCPU)が無い性質 Cap値を設けると メリット:CPUの”空き”が保証可能 デメリット:WCが満たされないため無駄が発生 11
結果:レイテンシ計測 0 5 10 15 20 25 30 35 30
ms no cap 5 ms no cap 30 ms cap 200(/400) ping RTT (msec) W/ NW BG mean max Creditスケジューラ(パラメタは調整) NW BG に対するcap: タイムスライス: 12
Credit2 スケジューラ • サポート開始 4.8~,デフォルト化 4.12~ • 変動タイムスライスでProportional Share(PS) •
タイムスライスは実行時に計算 • PS: 各VM(vCPU)はWeightに比例した時間割当て • Credit = Weightに応じ消費される実行時間 (UNDERとかOVERとかは存在しない) • よりレイテンシを抑えたいシステム向き※ ※Creditと比べて,スケーラブルという側面もある. 13 Wiki(更新されていない)曰く Credit2 is not in use by default.
Credit2 スケジューラ 基本アルゴリズム 全てのvCPUに 同量のCreditを配布 Credit最大vCPUを実行 実行時間分のCreditを消費して Runqをソート Credit が正の
vCPU存在? vCPUが存在 vCPUが存在しない 実行時間の決定アルゴリズム は次スライド 14
Credit2 スケジューラ タイムスライス決定アルゴリズム 1. Runqに他の実行待ちvCPUが… ある:c2t(実行予定vCPUのcredit - max(待ちvCPUのCredit)) ない:c2t(実行予定vCPUのcredit) 2.
1の値を次のパラメタで調整(上下限を設定) • ユーザ指定パラメタ: Cap, Rate Limit(=最短実行時間) • 静的なパラメタ: MIX(MIN)_TIMER ※ c2t(): credit を時間に変換する関数, Dom.のWeightに依存 最大credit 次に大きなcredit 15
Credit2 スケジューラ 基本アルゴリズム 全てのvCPUに 同量のCreditを配布 Credit最大vCPUを実行 実行時間分のCreditを消費して Runqをソート Credit が正の
vCPU存在? vCPUが存在 vCPUが存在しない 実行時間の決定アルゴリズム は次スライド 16
Credit2 スケジューラ 実行時間に応じたCredit消費 基本原理 • 大きなWeightをもつほどCreditの減りが遅い. • 最大Weightを持つvCPUは1nsで1credit消費 参考:Creditスケジューラは時間に応じた消費creditはす べてのVM共通だが,creditの分配量が異なる.
消費Credit = (実行時間(ns) * max(weights) + 補正)/ weight 17
Credit2 スケジューラ Event(IO)が発生したvCPUは… Runqに突っ込まれてCredit順にソートされ 最大CreditをもつvCPUを実行(tickle) 気持ち: • IO-boundなVMは待ち時間が多くcreditが減っていない ことが想定される. •
結果として,Event発生VMが優先されやすい. • 複数のVMが同時にIOしている状況に対応しやすい. ※厳密には,最短実行時間などパラメタで調整あり 18
結果:ping RTTの比較 0 0.5 1 1.5 2 2.5 no BG
w/ CPU BG w/ NW BG ping RTT (msec) mean max Credit2スケジューラ(パラメタはデフォルト) Tail の悪化が抑制 20
(再掲)結果:レイテンシ計測 0 5 10 15 20 25 30 35 30
ms no cap 5 ms no cap 30 ms cap 200(/400) ping RTT (msec) W/ NW BG mean max Creditスケジューラ(パラメタ調整) 21
今回話していないこと スケジューラの説明といいつつ… •ロードバランシング •スケーラビリティ •Realtime系のスケジューラ などの話題には触れていない. 22
まとめ • Xenのスケジューラの主要な2つを説明した. • Credit スケジューラ • 固定タイムスライス,Proportional Share •
IOレイテンシ削減のためにBOOST • 複数のBOOSTが同時に起こる環境ではレイテンシ大 • Credit2 スケジューラ • 変動タイムスライス,Proportional Share • レイテンシの観点で性能改善 23