kvm

kvm使用の場合とvmwareの場合で、どんな差が有るのだろう？ 気になるので、カーネルの コンパイル時間対決をやってみた。

なお、このOS劇場開演の際は、くれぐれも踊り子さん達には、お手を触れぬ様お願い 申し上げます。演技の進行がスムーズに出来ますようご協力下さい。 昭和のおじさんなら大概の人は知ってるだろうけど、若者はこういう環境に慣れて いないだろうからね。一応注意しましたよ。

qemu+kvmの場合

ctfstrip -S -o bsd bsd.gdb
   24m18.52s real    17m04.15s user     3m32.43s system

vmwareの場合

ctfstrip -S -o bsd bsd.gdb
   22m20.73s real    17m24.66s user     3m53.64s system

CPUリソースの使用時間って観点だと、kvmの方がやや勝っているな。体感時間なら、 vmwareの方が速い。この差はどんな要因によるのかな？ IO待ちになっててCPUが遊んで いるのなな。

おまけで、vmware環境で、make -j2と、欲ばって -j3

ctfstrip -S -o bsd bsd.gdb
j2   11m51.88s real    18m13.75s user     3m54.39s system
j3   11m55.78s real    18m39.06s user     3m59.45s system

アムダールの法則かな？ 昔から、船頭多くして船山に登る って言うからなあ。

時分秒の混在したデータって計算が面倒。pythonとかで正規表現パッケージを 使えば、容易に秒に均してしまえるだろう。でも、それって、あたり前すぎるんで。。。

(define (tos x)
  (let ((ans 0)
    (sv '())
    (ss (symbol->string x)))
  (set! sv (string-split ss #\m))
  (set! ans (+ ans (* 60 (string->number (car sv)))))
  (set! sv (string-split (cadr sv) #\s))
  (set! ans (+ ans (string->number (car sv))))
  ans))

ちょっとBUGが入っているけど、そして、らしからぬコードだけど、こんな風に 使う(vmware使用時の待ち時間の計算)。

scheme@(guile-user)> (tos '1m2.34s)
$1 = 62.34
scheme@(guile-user)> (apply - (map tos '(22m20.73s 17m24.66s 3m53.64s)))
$2 = 62.42999999999995

あんまりなので、らしく書いてみた。

(define ut '((#\h . 3600) (#\m . 60) (#\s . 1)))
(define uk '(#\h #\m #\s))

(define (tos-sub yet lv ans)
  (if (null? yet)
      ans
      (if (member (car yet) uk)
          (tos-sub (cdr yet) '()
               (+ ans
                  (* (cdr (assoc (car yet) ut))
                     (string->number (list->string (reverse lv))))))
          (tos-sub (cdr yet) (cons (car yet) lv) ans))))

(define (tos v)
  (tos-sub (string->list (symbol->string v)) '() 0))

;(tos '1m2.34s)

ちょっとメモしておく。便利なstring-splitみたいな手続は処理系依存で存在しない事がある (正にschemeが該当する)。文字列をスキャンして何かをしたい場合、string->list を使って 文字リストに変換してから処理。文字のリストを文字列に変換するには、list->stringを使用。

じゃ、スクリプトの解説をば。 utは想像通り、時分秒の重みテーブル。ukは単位(hms)の記号文字リスト。utで代用 できるけど、それじゃ糞味噌一緒で趣味に合わないので、分離した。

tos-subは後廻しにして、 先にtosの説明。 たいした事はやってなくて、変換したい入力データ(シンボル扱い)を受け取って、詳細はtos-subに丸投げする為のインターフェース。

tos-subは3個の引数を使い廻す再帰関数。yetは、まだ解析が終了していないリスト。この リストが空になると、変換結果がansに確定した事になる。lvは単位以外の文字(数字と小数点) を貯め込。

2個目のifで、単位かどうかを判定。若し単位なら、その時のlvに単位の重みを乗算して から、ansに加算。そしてlvを空にしてから、次のデータに取りかかる。数値なら、それをlvに 貯め込んで、次のでデータに取りかかる(自分自身の呼び出し)。

特殊な関数は利用していないので、schemeでも動作する。 tos-subをトレースして、引数の変化を確認してみる。

sakae@lu:~$ scheme tos.scm
Chez Scheme Version 9.5.8
Copyright 1984-2022 Cisco Systems, Inc.

> (trace tos-sub)
(tos-sub)
> (tos '1h23m45s)
|(tos-sub (#\1 #\h #\2 #\3 #\m #\4 #\5 #\s) () 0)
|(tos-sub (#\h #\2 #\3 #\m #\4 #\5 #\s) (#\1) 0)
|(tos-sub (#\2 #\3 #\m #\4 #\5 #\s) () 3600)
|(tos-sub (#\3 #\m #\4 #\5 #\s) (#\2) 3600)
|(tos-sub (#\m #\4 #\5 #\s) (#\3 #\2) 3600)
|(tos-sub (#\4 #\5 #\s) () 4980)
|(tos-sub (#\5 #\s) (#\4) 4980)
|(tos-sub (#\s) (#\5 #\4) 4980)
|(tos-sub () () 5025)
|5025
5025

シングルCPUとディアルCPUでの実行時間比率を求めてみた。

> (apply / (map tos '(11m51.88s  22m20.73s)))
0.5309644745772825

本来なら2CPUが動作するんで、0.5になるはずだけど、余分な手間がかかっているか、 並列化できない部分が有って、効率が悪くなっている。

Q: このデータから何が言えるか、レポートを作成してください。

A: ### 仮想環境におけるOpenBSDカーネルコンパイル時間の比較と考察

#### 1. はじめに 仮想環境における性能評価は、システム管理者や開発者にとって重要な関心事である。本レポートでは、Ubuntu上に構築したKVM+QEMU環境とVMware環境の2つの仮想環境において、OpenBSDのカーネルコンパイル時間を計測し、その結果をもとに両者のパフォーマンスの違いを考察する。

#### 2. 実験環境

• ホストOS: Ubuntu
• 仮想化環境:
  • KVM+QEMU
  • VMware
• ゲストOS: OpenBSD
• 測定方法: `time` コマンドを用いてカーネルのコンパイル時間を測定
• 測定結果:
  • KVM+QEMU:
    • `real` (実時間): 24m18.52s
    • `user` (ユーザーモードCPU時間): 17m04.15s
    • `system` (カーネルモードCPU時間): 3m32.43s
  • VMware:
    • `real` (実時間): 22m20.73s
    • `user` (ユーザーモードCPU時間): 17m24.66s
    • `system` (カーネルモードCPU時間): 3m53.64s

#### 3. 結果の分析 ##### 3.1 `real` 時間の比較

• KVM+QEMU: 24m18.52s
• VMware: 22m20.73s
• → VMwareの方が 1分57秒 速い

`real` 時間は、実際に処理が完了するまでの経過時間を示す。この結果から、VMware環境の方が約**8%高速**であることがわかる。

##### 3.2 `user` 時間の比較

• KVM+QEMU: 17m04.15s
• VMware: 17m24.66s
• → KVM+QEMUの方が 20秒 速い

`user` 時間は、プロセスがCPUを使用していた時間を示す。興味深いことに、KVM+QEMUの方が **若干短い**。これは、KVMがより効率的にCPUを利用している可能性を示唆する。

##### 3.3 `system` 時間の比較

• KVM+QEMU: 3m32.43s
• VMware: 3m53.64s
• → KVM+QEMUの方が 21秒 速い

`system` 時間は、カーネルモードでのCPU処理時間を示す。この結果から、KVM+QEMUのカーネル処理がより効率的である可能性がある。

##### 3.4 `real` と `user+system` の差分

• KVM+QEMU: `24m18.52s - (17m04.15s + 3m32.43s) = 3m42s`
• VMware: `22m20.73s - (17m24.66s + 3m53.64s) = 1m02s`

この差分は、CPUが実際に処理を行っていない待機時間（I/O待ちやコンテキストスイッチなど）を反映する。VMwareでは **待機時間が短く**、より効率的にリソースが使用されていることが推測できる。

#### 4. 仮想化技術の影響 ##### 4.1 KVM+QEMU KVM（Kernel-based Virtual Machine）はLinuxカーネルに組み込まれた仮想化技術であり、QEMUと組み合わせることで仮想マシンを実行する。KVMはハードウェアの仮想化支援機能（VT-x, AMD-V）を活用するが、QEMUを介することで一部の処理にオーバーヘッドが発生する可能性がある。

##### 4.2 VMware VMwareは、長年にわたり開発されてきた商用仮想化ソリューションであり、パフォーマンス最適化が進んでいる。特に、I/O処理やスケジューリングの最適化がKVM+QEMUより優れている可能性がある。

#### 5. パフォーマンス差の要因

1. I/O処理の最適化
   • VMwareの方がI/O待ち時間が短い可能性がある。
2. CPUスケジューリングの違い
   • `user` 時間はほぼ同じだが、KVM+QEMUの方が `real` 時間が長い。VMwareのスケジューリングの方が効率的かもしれない。
3. オーバーヘッドの違い
   • KVM+QEMUはQEMUを介するため、若干のオーバーヘッドが発生する可能性がある。

#### 6. 結論と今後の課題 本レポートでは、Ubuntu上に構築したKVM+QEMUとVMwareの仮想環境におけるOpenBSDカーネルコンパイル時間を比較し、VMwareの方が約8%高速であることを確認した。今後の課題として、

• 仮想マシンの設定（CPUコア数、メモリ量）を変更し、パフォーマンスの影響を調査する
• 他のワークロード（例えば、I/O負荷の高い処理）でも比較し、総合的な性能評価を行う

といった追加実験が考えられる。

CPUスケジューリングについては、リナのカーネル 6.13(だったか)で、改善されるのかな？

第2段の実験をします。河豚板 7.6のリアル・マシン(おまけに8G RAMのみで稼動)と、vmware でのカーネル・コンパイル比較です。ターン・アラウンドを早く欲しいので、ディアルCPUで 実験。

VMware  11m51.88s real    18m13.75s user     3m54.39s system
Real    11m03.55s real    15m51.79s user     2m46.20s system

当然リアル・マシンが速いけど、VMwareにはハンディが有る。それは、コンパイルの進行に 伴なって作成される *.o, *.d がSSDに書き込まれる事だ。幾らSSDが速いと言っても それなりの時間はかかるはず。で、生成物をダミーのdirにcpする事で、確認しとく。

time cp *.o *.d dummy/

VMware(SSD)  0m12.76s real     0m00.12s user     0m07.07s system
Real(RAM)    0m01.71s real     0m00.03s user     0m01.62s system

cpしたファイルの総個数は4600個、総容量は540Mbyteだった。

Q: この結果を元に考察レポートを作成してください(丸投げだ。堕落だ!)。

A: ### VMwareとリアルマシンにおけるOpenBSDカーネルコンパイル時間とI/O性能の比較

#### 1. はじめに 仮想環境とリアルマシンの性能比較は、システムの最適化やパフォーマンスチューニングにおいて重要な課題である。本レポートでは、VMwareとリアルマシンでOpenBSDを稼働させ、カーネルのコンパイル時間およびI/O性能の違いを比較し、両者の特性を考察する。

#### 2. 実験環境と測定方法

• 仮想環境: VMware（SSD上に配置）
• リアルマシン: 物理ハードウェア上でOpenBSDを稼働（RAM 8GB）
• ビルド環境: `make -j2`（2コアを使用）
• 測定方法:
  1. カーネルコンパイル時間 (`time make -j2`)
  2. I/O性能評価 (`time cp *.o *.d dummy/`)

#### 3. 測定結果と比較

##### 3.1 カーネルコンパイル時間

環境	`real` (実時間)	`user` (ユーザーモードCPU時間)	`system` (カーネルモードCPU時間)
VMware (SSD)	11m51.88s	18m13.75s	3m54.39s
Real (RAM)	11m03.55s	15m51.79s	2m46.20s

###### 分析

• `real` 時間: リアルマシンの方が 48秒 速い（約7%の差）
• `user` 時間: VMwareは 18分13秒**、リアルマシンは **15分51秒 で、VMwareの方が 2分22秒長い
• `system` 時間: VMwareは 3分54秒**、リアルマシンは **2分46秒 で、VMwareの方が 1分8秒長い

→ VMwareではCPUの負荷が高く、カーネルモードの処理時間も長くなっている ことがわかる。

##### 3.2 I/O性能（ファイルコピー）

環境	`real` (実時間)	`user` (ユーザーモードCPU時間)	`system` (カーネルモードCPU時間)
VMware (SSD)	0m12.76s	0m00.12s	0m07.07s
Real (RAM)	0m01.71s	0m00.03s	0m01.62s

###### 分析

• `real` 時間: VMwareは **12.76秒**、リアルマシンは **1.71秒**（**約7.5倍の差**）
• `system` 時間: VMwareは **7.07秒**、リアルマシンは **1.62秒**（**約4.3倍の差**）

→ VMwareのI/O処理はリアルマシンより大幅に遅い ことがわかる。

#### 4. 仮想環境とリアルマシンの違いの考察

##### 4.1 CPU性能の違い

• `user` 時間の差（VMwareの方が2分22秒長い）から、**VMwareのCPUオーバーヘッドが大きい** ことがわかる。
• 仮想化環境では、ホストOSがCPUを管理し、ゲストOSに対するスケジューリングが発生するため、リアルマシンよりも効率が落ちる。
• `system` 時間もVMwareの方が長いことから、**仮想環境のカーネル処理のオーバーヘッドが高い** ことが推測できる。

##### 4.2 I/O性能の違い

• VMwareはSSDを使用しているが、それでもRAM上のリアルマシンと比べると **約7.5倍遅い**。
• `system` 時間の差（VMwareの方が約4.3倍長い）から、仮想ディスクのI/O処理に大きなオーバーヘッドがあることが示唆される。
• SSDは高速だが、VMwareでは**仮想ディスクの管理やキャッシュ処理の影響でI/O性能が低下**している可能性がある。

##### 4.3 カーネルコンパイルにおけるI/Oの影響

• カーネルコンパイルでは、**大量のオブジェクトファイル（*.o, .d）が生成・読み書き* されるため、I/O性能が重要になる。
• VMwareでは**仮想ディスクのオーバーヘッド** が影響し、I/O処理の負担が増している。
• それにより、**CPUの`user`時間と`system`時間も増加**し、`real`時間が長くなったと考えられる。

#### 5. 結論

1. CPUオーバーヘッド:
   • VMwareではCPUの`user`時間が長くなり、処理効率が低下している。
   • 仮想環境のスケジューリングによる遅延が影響している可能性が高い。
2. I/Oオーバーヘッド:
   • VMwareのI/O処理はリアルマシンより **約7.5倍遅い**。
   • 仮想ディスクの管理やキャッシュ処理の影響で、ディスクI/Oの効率が悪化している。
   • カーネルコンパイルではI/O負荷が高いため、仮想環境のオーバーヘッドが顕著に表れた。
3. カーネルコンパイルにおける影響:
   • VMwareでは **I/O性能の低下がCPU負荷の増加を引き起こし**、コンパイル時間の延長につながっている。
   • I/O負荷が高いタスクでは、仮想環境よりリアルマシンの方が圧倒的に有利である。

#### 6. 今後の課題と改善策

1. VMwareのI/O最適化:
   • 仮想ディスクを NVMeパススルー で設定し、I/Oボトルネックを改善する。
   • メモリ割り当てを増やし、ファイルキャッシュを活用 することで、I/O処理を軽減する。
2. CPUオーバーヘッドの削減:
   • VMwareの 仮想CPU設定を最適化（例えば、CPUパススルー） し、パフォーマンス向上を図る。
   • `make -j2` のスレッド数を調整し、CPUのスケジューリングを最適化する。
3. 仮想環境の用途最適化:
   • I/O負荷の高いタスク（コンパイル、データベース） はリアルマシンで実行する。
   • 仮想環境は CPU計算中心のタスク（スクリプト処理など） に適用する方が有利。

この結果を踏まえると、**I/O負荷が高い処理では仮想環境よりリアルマシンの方が圧倒的に優位** であり、用途に応じた環境選択が重要である。

Q: make -j1 と make -j2 の結果をアムダールの法則を加味して検討してください。 リンカーやストリップに多大な時間を要してるように見受けられます。

A: ### VMwareにおけるシングルCPU vs デュアルCPUの比較と並列処理の影響

#### 1. はじめに 本レポートでは、VMware環境において**シングルCPUとデュアルCPUでのOpenBSDカーネルのコンパイル時間**を比較し、並列化の影響を評価する。また、アムダールの法則に基づいて、**並列化による性能向上の限界**を検討する。さらに、コンパイル終盤に発生する**リンカー処理やデバッグ情報のストリップ作業**の影響についても考察する。

—

#### 2. 実験結果

CPU数	`real` (実時間)	`user` (ユーザーモードCPU時間)	`system` (カーネルモードCPU時間)
1CPU	22m20.73s	17m24.66s	3m53.64s
2CPU (`make -j2`)	11m51.88s	18m13.75s	3m54.39s

• `real` (実時間) は約1.88倍の高速化
• `user` 時間の増加 (17m24.66s → 18m13.75s)
  • 2つのCPUが並列で動作するため、`user` の合計時間は増加する。
• `system` 時間はほぼ変化なし (3m53.64s → 3m54.39s)
  • システムコールやI/Oの負荷は大きく変わらない。

—

#### 3. アムダールの法則による性能評価 並列処理の限界を評価するため、アムダールの法則を適用する。アムダールの法則は以下の式で表される：

\[ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} \]

ここで：

• \( S(N) \) ：N個のCPUを使用したときの加速比
• \( P \) ：並列化可能な割合
• \( N \) ：CPU数

#### (1) 実測データから並列化可能な割合 \( P \) を推定 加速比 \( S(N) \) は次のように計算できる。

\[ S(2) = \frac{22.35}{11.86} \approx 1.88 \]

アムダールの法則の式を変形して \( P \) を求める：

\[ 1.88 = \frac{1}{(1 - P) + \frac{P}{2}} \]

\[ (1 - P) + \frac{P}{2} = \frac{1}{1.88} \]

\[ 1 - P + \frac{P}{2} = 0.532 \]

\[ 1 - 0.532 = P - \frac{P}{2} \]

\[ 0.468 = \frac{P}{2} \]

\[ P \approx 0.936 \]

つまり、**カーネルコンパイル全体の約93.6%が並列化可能** であり、残りの**6.4%がシリアル処理**である。

—

#### 4. コンパイル終盤のリンカー処理・デバッグ情報のストリップ作業 コンパイルの進行を観察すると、終盤に**リンカー処理やデバッグ情報のストリップ作業**に時間がかかっていることがわかる。

##### (1) リンカー処理

• `ld` (リンカ) は複数のオブジェクトファイルを結合して最終的なカーネルバイナリを作成する。
• **並列化できずシングルスレッドで動作するため、2CPU環境でも実行時間が短縮されない**。

##### (2) デバッグ情報のストリップ

• `strip` コマンドはバイナリからデバッグ情報を削除する作業であり、基本的にシングルスレッド処理。
• 1つの大きなバイナリに対する処理なので、並列化の恩恵を受けにくい。

##### (3) `real` 時間の短縮が理論値より小さい理由

• アムダールの法則によると、**完全な並列処理なら2倍の速度向上**が可能だが、実際のデータでは**約1.88倍の向上**にとどまっている。
• **リンカーやストリップ作業がボトルネックとなり、並列化の恩恵を制限している**。

—

#### 5. 改善策と最適化 ##### (1) `make -j` の最適化

• `make -j2` は2つのCPUを効率的に使うが、`make -j3` なども試す価値がある（スケジューリングの影響）。
• CPU数の1.5倍程度 (`make -j3` など) で試し、最適な `-j` の値を見つける。

##### (2) I/Oボトルネックの軽減

• 仮想マシンの仮想ディスクI/Oを最適化
  • **NVMeパススルーの利用**（物理SSDの性能をより活かす）
  • **キャッシュ設定を調整**（書き込みキャッシュを有効化）
  • **RAMディスクの利用**（`/tmp` を `tmpfs` に設定し、コンパイル中の一時ファイルのI/O負荷を軽減）

##### (3) 終盤のシリアル処理の高速化

• **リンカーの並列化**：
  • `ld.gold` や `lld` などのより高速なリンカを試す。
• **デバッグ情報のストリップの最適化**：
  • `strip` のオプションを見直し、不要な処理を削減する。

—

#### 6. まとめ

• **デュアルCPUでは、シングルCPUの約1.88倍の速度向上を達成**。
• カーネルコンパイル全体の約93.6%が並列化可能 であり、アムダールの法則の影響を受ける。
• 終盤のリンカー処理やデバッグ情報のストリップ作業はシングルスレッド処理 のため、並列化の恩恵が小さい。
• **仮想環境のI/O最適化や、リンカの変更により、さらなる性能向上が可能**。

このように、コンパイル全体の流れを分析し、並列化が効く部分と効かない部分を理解することで、より効率的な環境を構築できる。

河豚板が出てきたけど、あちらにも仮想PCが有ったなあ。あちらでも、やってみたいな。 手間がかかるけど。

上記提案中に、/tmp を tmpfs に設定し、コンパイル中の一時ファイルのI/O負荷を軽減 なんてのが出てきた。Lubuntuでは、/tmpがtmpfsに設定(搭載メモリーの半分)されている ので、積極的に/tmpを使うべし。

sakae@lu:~$ df -m
Filesystem     1M-blocks  Used Available Use% Mounted on
tmpfs                783     2       781   1% /run
tmpfs               3913    17      3896   1% /dev/shm
tmpfs                  5     1         5   1% /run/lock
tmpfs               3913     0      3913   0% /run/qemu
tmpfs               3913     3      3911   1% /tmp

カーネル・コンパイルの残骸をLubuntuに輸出してRAM(/tmp)とSSD($HOME)にcpし、性能比較を してみる。リナのtime出力は、比較に不適なんで、ちょいと編集。全く、リナはオプションが 豊富な割りに、使い心地が悪い。

RAM   real    0m0.412s  user    0m0.053s  sys     0m0.359s
SSD   real    0m0.851s  user    0m0.101s  sys     0m0.750s

本質的な物理デバイスの書き込みスピード差は(0.391s)だな。

更に参考で、3.3G有るLubuntuのISOファイルをcp

RAM   real    0m04.207s  user    0m0.055s  sys     0m2.462s
SSD   real    0m15.691s  user    0m0.001s  sys     0m5.338s

RAMで待ち時間が有るのは、エリアの確保が大変なんだろうな。SSDでの待ちは やはり消去・書き込みって操作がSSD内部で実施するって事情なんだろうね。

本当はバッファー/キャッシュの影響を排除しつつRAMに書き込むのが正しい比較 なんだけど、手元にそんな都合の良いファイルが無かったので、お茶を濁した。

バッファーの影響を排除(バイパス)した、真のデバイスの書き込み性能。

sakae@lu:tmp$ dd if=/dev/zero of=/tmp/xx bs=1M count=1024 oflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.456391 s, 2.4 GB/s
sakae@lu:tmp$ dd if=/dev/zero of=~/xx bs=1M count=1024 oflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.47385 s, 309 MB/s