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