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.2k
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
850
C言語プログラムの構造とほんの少し解釈
mu_mu_mu
3
1.5k
Intel MPK入門
mu_mu_mu
0
590
Other Decks in Programming
See All in Programming
Ruby on cygwin 2025-02
fd0
0
150
Honoのおもしろいミドルウェアをみてみよう
yusukebe
1
210
CI改善もDatadogとともに
taumu
0
170
仕様変更に耐えるための"今の"DRY原則を考える
mkmk884
7
2.3k
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
12
4.4k
Pythonでもちょっとリッチな見た目のアプリを設計してみる
ueponx
1
590
DRFを少しずつ オニオンアーキテクチャに寄せていく DjangoCongress JP 2025
nealle
2
180
パスキーのすべて ── 導入・UX設計・実装の紹介 / 20250213 パスキー開発者の集い
kuralab
3
830
第3回 Snowflake 中部ユーザ会- dbt × Snowflake ハンズオン
hoto17296
4
380
Honoをフロントエンドで使う 3つのやり方
yusukebe
7
3.4k
Djangoにおける複数ユーザー種別認証の設計アプローチ@DjangoCongress JP 2025
delhi09
PRO
4
380
Java Webフレームワークの現状 / java web framework at burikaigi
kishida
9
2.2k
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
Mobile First: as difficult as doing things right
swwweet
223
9.3k
Speed Design
sergeychernyshev
27
800
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
9
500
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Agile that works and the tools we love
rasmusluckow
328
21k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Being A Developer After 40
akosma
89
590k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.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