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
800
C言語プログラムの構造とほんの少し解釈
mu_mu_mu
3
1.5k
Intel MPK入門
mu_mu_mu
0
550
Other Decks in Programming
See All in Programming
What’s New in Compose Multiplatform - A Live Tour (droidcon London 2024)
zsmb
1
350
RailsのPull requestsのレビューの時に私が考えていること
yahonda
5
1.9k
飲食業界向けマルチプロダクトを実現させる開発体制とリアルな現状
hiroya0601
1
400
ECSのサービス間通信 4つの方法を比較する 〜Canary,Blue/Greenも添えて〜
tkikuc
11
2.3k
CSC305 Lecture 13
javiergs
PRO
0
130
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ~俺のやらかしを越えてゆけ~
techouse
52
32k
色々なIaCツールを実際に触って比較してみる
iriikeita
0
280
現場で役立つモデリング 超入門
masuda220
PRO
13
3k
外部システム連携先が10を超えるシステムでのアーキテクチャ設計・実装事例
kiwasaki
1
230
Synchronizationを支える技術
s_shimotori
1
150
推し活の ハイトラフィックに立ち向かう Railsとアーキテクチャ - Kaigi on Rails 2024
falcon8823
6
2.3k
/←このスケジュール表に立ち向かう フロントエンド開発戦略 / A front-end development strategy to tackle a single-slash schedule.
nrslib
1
590
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
519
39k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
228
52k
Rails Girls Zürich Keynote
gr2m
93
13k
Fontdeck: Realign not Redesign
paulrobertlloyd
81
5.2k
The Language of Interfaces
destraynor
154
24k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
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