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
Performance tuning of VMM using KVM
Search
YushoYamaguchi
March 20, 2026
300
0
Share
Performance tuning of VMM using KVM
YushoYamaguchi
March 20, 2026
More Decks by YushoYamaguchi
See All by YushoYamaguchi
OpenStack Tenant Network Isolation: Considerations and Practical Examples
yushoyamaguchi
0
340
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Designing for humans not robots
tammielis
254
26k
The World Runs on Bad Software
bkeepers
PRO
72
12k
What's in a price? How to price your products and services
michaelherold
247
13k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.8k
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
93
Done Done
chrislema
186
16k
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
700
Designing for Performance
lara
611
70k
WENDY [Excerpt]
tessaabrams
9
37k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Transcript
KVMを使うVMMの 性能ボトルネック解析をした話 Yamaguchi Yusho 1
自己紹介 • 仮想化技術とネットワーク技術とOSSが好きな駆け出しエンジニア • 仕事は通信キャリアでプライベートクラウドの開発運用をしている oOpenStack(クラウドを作るためのOSS)を利用して構築 o 今回のテーマであるKVMには大変お世話になっている 2
前提知識 • KVM: • Linux Kernel内でVMを動かすためのフレームワーク • 各CPUの仮想化支援機構を利用してゲストコードを実行するため、シンプル な命令実行はネイティブ並みに高速 •
デバイスエミュレーション等に関しては後述のVMMに任せる • Kernel Moduleであり、ioctlシステムコールを使って操作 • KVMを使うVMM • OSなどのゲストワークロードを動かすためのKVMのセッティング→起動 • KVMが処理できないゲストの命令(デバイスI/Oなど)をエミュレーションして結 果をゲストに伝える 等の役割を果たすソフトウェア (有名なもので言うとQEMU-KVM) 3
今回やったこと • 簡易なVMM上で簡易なゲストOSを動かして、仮想化技術に対する理解 を深めたい! • 利用したソフトウェアは以下 • VMM: kvmm oDisk/Serial/割込Controller
のみをエミュレートした簡易なVMM ohttps://github.com/yushoyamaguchi/kvmm • ゲストOS: jos oMITのOS開発の授業で利用されているC言語製の簡易なOS ohttps://github.com/yushoyamaguchi/my_jos/tree/kvmm_lab3 4
VMM実行の流れ 5 • カーネル→ユーザスペース • ユーザスペース→カーネル
動かしてみた結果 • kvmm上でjosが起動はするが、ものすごーーく遅い o1コマンド実行に1分くらいかかる • QEMU上でjosを動かすと、サクサク動く • → 原因究明の旅に 6
切り分け1: VMM側にデバッグプリントを入れ てどこに時間がかかっているかを知る • KVMを呼んでからEXITするまでの時間が、kvmm側でデバイスエミュ レーションしている時間の、約80倍かかっている 7 10桁 9桁
切り分け2: Perfで解析 • VCPU へのEnter 自体にとても多くの時間がかかっている • 仮説: Exit→ 再Enterが頻発しすぎている...?
8
切り分け3: Exitの主要原因を調査 • ゲストでのI/O命令実行に伴うExitが圧倒的に多い • QEMU上で実行した時は、ここまで偏りがなかった • デバッグプリント入れたところ、0x84番ポートへのI/Oがほとんど 9
切り分け4: ゲストOSのコードから 該当PortへのI/Oをしている箇所を探す • delay() 関数 ...? • このdeley()を呼び出しているのはどこ? 10
原因判明! • シリアルポートの中のレジスタをポーリングして、Ready bit が立つま で待つコード(上限回数12800回) • kvmmではこのデバイスのエミュレーションをしていなかった o そのためReadyになることがない
• この処理が、consoleへの出力時に毎回呼ばれていた • その度に毎回大量のI/O-Exitが発生 11
総括 • この部分のコードをゲストOSからコメントアウトしたら、kvmm上でも サクサク動いた • I/O Exit → 再Enterに伴って起こるシステムコール呼び出しに莫大な オーバーヘッドが存在
12
おまけ: この知識が仕事に役立った話 • 運用しているOpenStack基盤で、CPUコアを占有してパケット処理を する(DPDK)VMが、想定通りのパフォーマンスを出せていないという 問い合わせを受けた • VMの統計情報を見ると、CPU HaltによるExitが頻発していることが 判明→コアを占有するはずなのにおかしい...
• VM 実装者に問い合わせたところ、動作想定よりvirtioキューが少な い環境であり、CPU時間を手放してしまっていることが判明 13