30分で論文流し読みシリーズ1: 「Schedule Processes, not VCPUs」

最近思うところあって意識的に論文を読んでみようかなと思うようになりました。幸いにも研究者およびその卵である友人がいたので、いろいろ勧めてもらったものを読むことにしました。それらについてさらっと読んで要約して自分なりの感想をまとめてみようかなと思ってます。

初回はSchedule Processes, not VCPUs

  • 実際の所要時間 一時間

  • 概要

    • 設定した問題: 仮想マシンにおいてははハイパーバイザによるvCPUのスケジューリングと仮想マシン上のプロセスのスケジューリングが二重にあることによっていろいろ問題があるのでそいつを解決しようぜ
    • 解決方法: どうやるのかというとゲストのvCPU数をハイパーバイザから見た負荷に応じて動的に変更させる。筆者はこの方法をvCPU-Balloningと呼んでいる。
    • 効果: 12コアのXeonマシンにおいて所定の処理の所要時間がXenにおいて1.5%から57.9%、KVMにおいて8.2%から63.8%高速になった。本記事では具体的にどういう処理を動かしたのかについては踏み込まない
  • 問題詳細

    • あるvCPU上でロック取ろうとした後に当該vCPUが乗ってるpCPU上でホストの処理ないし別vCPUの処理が動いた場合、以下のような様々な問題が発生する
      • vCPU Preemption
      • vCPU Stacking
      • CPU Fragmentation
      • priority inversion
  • 解決方法詳細

    • 以下によってpCPU上に複数vCPUを割り当てる事態の発生を最小限に抑えることによって設定した問題の発生を最小限に抑える
      1. 各ゲストにweightを与える
      2. 各ゲストにweight(全VMのweight合計)を整数値に丸めたターゲットvCPU数を設定する
      3. 各ゲストにターゲットvCPUを割り当ててそれぞれpinする。ターゲットvCPU数に増減がある場合はたとえばCPU hotplugによってvCPU数を増減させる
      4. ゲスト数が増減するときに2に戻る
  • 課題

    • ゲストのアプリがvCPU数の変動に対応しなくてはいけない
    • vCPU数を整数値に丸める必要があるので精度がそんなによくない
  • 感想

    • 論文のタイトルと実際論文で取り組んだことが一致してないように思う
    • これはそのそも解かなきゃならない問題なのか?
      • IaaSであればvCPUは通常占有させる
      • pCPUを複数vCPUで共有させる場合は性能をそれほど気にするほど頑張る必要はあるのか?
    • ゲスト上のアプリから見てvCPU数がコロコロ変わるのってけっこう辛くない?
    • 現在進行形で問題が起きていてもVMの生成/終了まで状況は改善しないのね
    • ロックの問題とスケーラビリティの問題がごちゃごちゃしてる
  • 自分ならどうする(既存研究があるとかないとかは知らない)?

    • weghtはとくに設定しない。vCPU数も変動させない
    • vCPUがアイドルになったらホストに通知する
      • そのvCPUが乗っているpCPU上にはvCPUは一つも乗っていないとみなす
      • vCPUがアイドルになるたびに上記のことをしているとオーバーヘッドが大きいのでアイドルになってから一定以上の時間が経つとvCPUを使っていない状態にするという閾値を設ける、などの凝った作りにしてもいい
    • この方法であればゲストから見たvCPU数は変化しない