2010年12月22日水曜日

FreeBSD用virtioドライバ ステータスアップデート (2010/12/21)

10月頃に作成したFreeBSD用virtioドライバですが、その後もボチボチと作業を続けております。

これまで開発した範囲では性能問題なども一通り解決しているので、
もうすこしコードを整理して、 -STABLE 品質として必要な機能を追加したら
ドライバをメーリングリストなどに投稿したいと思っています。

各ドライバのステータスなどについて紹介します。



■ 機能ドライバのステータス


  • virtio-net


    • vCPU = 1, 2の場合に e1000 エミュレーションよりスループットが高くなるよう改善

    • シャドウページテーブル環境下におけるパフォーマンス悪化を改善

    • メモリ管理方式の変更(malloc→bus_dmaによる連続したGuest-Physicalメモリ空間の確保)

    • OSにより確保されるmbufへの直接データ受信、バッファの再利用による高速化

    • 途中: Merged RX Buffers

    • 未: Hardware Checksum Offload

    • 未: GSO

    • 未: TSO

    • 未: Promiscous mode support, MAC Address filtering, Tagged VLAN Support

    • 未: MSI-X support

    • 未: Driver Media Status/Statics support

  • virtio-blk (新たに実装)


    • vCPU = 1, 2 の場合に SCSI Emulation よりも高性能、かつ CPU 負荷が低下するよう実装

      ※ qemu-kvm + FreeBSD は相性が悪いらしく、これだけでは性能は不十分

    • 済: VIRTIO_BLK_T オペレーション (ディスクへの単純読み書き)

    • 済: FLUSH オペレーション

    • 未: SCSI Device Passthrough

その他 Memory Balloon, Console は未着手

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

テープデバイス/dev/rmt/Xのデバイス番号をリセットする

Solaris 環境でテープデバイスを認識させる場合、基本的には /dev/rmt/0 から 1, 2, 3, ... と順番に番号が振られます。

しかし、機器移設時にテープドライブの接続先ポートを間違えたり、テープドライバの個体 ID が変わったりすると、「それまではとは違うテープドライブ」と認識され、意図せず /dev/rmt/1, /dev/rmt/2, ... とデバイス番号が進んでしまう場合があります。

このような場合には、まず /dev/rmt/ 以下にあるデバイスファイルを削除した後にテープドライブを接続して再起動すると、 Solaris 起動時にドライバ？がテープのデバイスファイルを適切に作成しなおしてくれます。



# cd /dev/rmt
# rm 0*                     ※チキンなので * ではなく 0* などとしました:p
# rm 1*
# shutdown -y -g0 -i6

システム起動時のテープドライブがどのデバイス名で認識されているかは cfgadm -al コマンドにて確認できます。

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2010年12月5日日曜日

FreeBSD + KVMの環境でちょっと過ごしてみてわかってきたノウハウ（１）

最近 FreeBSD 用の virtio ドライバに割と情熱を注いでいるのですが（そろそろ公開したい！）、
ドライバの性能が出ないという状況になって調査したときに多少ノウハウが得られたのでメモがてら掲載しておきます。

まずの一つ目のネタ。kvm_statコマンド。

kvm statistics

 efer_reload                  0       0
 exits                401230913    2152
 fpu_reload               52997       0
 halt_exits           133189538     757
 halt_wakeup            5259576      15
 host_state_reload    170030018     977
 hypercalls                   0       0
 insn_emulation       252392427    1359
 insn_emulation_fail          0       0
 invlpg                 2684292       0
 io_exits               4130425      17
 irq_exits              8935347      39
 irq_injections         3195682       0
 irq_window                   0       0
 largepages                   0       0
 mmio_exits            28482276     179
 mmu_cache_miss          698023       0
 mmu_flooded              40079       0
 mmu_pde_zapped          216076       0
 mmu_pte_updated         180285       0
 mmu_pte_write          1931218       0
 mmu_recycled                 0       0
 mmu_shadow_zapped       696204       0
 mmu_unsync                 877       0
 nmi_injections               0       0
 nmi_window                   0       0
 pf_fixed               4719781       0
 pf_guest                817765       0
 remote_tlb_flush        234452       0
 request_irq                  0       0
 signal_exits                 0       0
 tlb_flush              4903428       0

性能が出ていない場合には非常に参考になる内容です。ソースコードなどを見て何をしてくれているのか調査したわけではないのですが・・・





exits
発生したVMEXITすべての回数を示します。VMEXITとはIntel VT/AMD-VのCPU仮想化支援技術においてVMを実行し、何らかの理由（I/Oとかメモリ管理で何かがおきてVMMの介入が必要になったとか、タイムスライスを使い切ったとか色々）によりゲストを停止させた回数になります。仮想化支援技術があったとしてもVMMモード／ゲストモードの切り替えは非常にコストの高いものなので、これをいかに削減するかがポイントになります。



insn_emulation
それまでに発生したハードウェアエミュレーションの回数？を示しているようですが、細かいことは未調査。

io_exits

I/Oポートに対するアクセスで発生したVMEXITの回数を示します。
この値が大きくなる場合はハードウェアへのI/Oが頻発しており
性能劣化につながっていることが予想されます。
このような操作は全てVMEXITを引き起こしますので、いかにI/Oポートアクセスなどを少ない回数で済まさせるかが、VMの実質実効時間をのばすためにVMEXIT回数を削減するという観点で気になる数字です。

irq_exits

VMの実行中、物理ハードウェアにからの割り込みによってVMEXITした回数を示しているようです。この数字が大きい場合は物理ハードウェア側のIRQ割り込みをいかに減らすかの検討が必要になりそうです……。

irq_injections

ハードウェアエミュレータ(qemu-kvm)がVMに対して発行した割り込みの回数を示します。
IRQを使用している場合、IRQが発生すると、IRQをシェアするデバイスドライバ群が
ISR(Interrupt Status Register)をポーリングします。
このため割り込み回数×IRQ・・・と、共有するデバイス数が多いほどVMEXITの発生回数も増加にも繋がることから、ドライバを作るのであればこれをいかに低く抑えるかがポイントになります。

mmio_exits

メモリマップドI/OのためのVMEXIT回数です。

mmu_pte_write

シャドウページテーブル利用時、VM内のページテーブルのエントリ(Page Table Entry)を更新した数を示すようです。この値は、たとえばゲストOS上でmalloc()やfree()を行った場合にも実装次第で発生します。値が大きい場合は仮想マシン上のメモリ管理機構について再検討する余地があると言えます。この値はEPT/NPTが利用できないハードウェアでシャドウページテーブルによる負荷を見るのに利用できます。ここはゲスト内のプログラムのメモリ管理を工夫することで削減が可能です。ドライバなどであれば普段利用中にゼロから動かさせない、ぐらい高い目標を持ってもよいでしょう。


投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2010年10月20日水曜日

virtio for FreeBSD: Current Status (2010/10/20)

Hello World!
I decided to write virtio frontend drivers for FreeBSD because I wanted to understand how virtio works.
My virtio-net drivers began to work in the middle of October, so I'm guessing that I would offer the driver for FreeBSD community.
Actually there are some tasks to do before release it, so I need some time (and some help:).


Current Status (virtio-net)

  • virtio-net driver is working on a 1vCPU virtual machine. Tested more than 300GB of TX and RX.

  • almost same performance with e1000 (check out the graph below)

  • no offload functions provided (I think it is not so needed now)


Development Environment

  • Host: Fedora 14 alpha x86_64

  • Guest: FreeBSD 8.1-RELEASE, amd64


Least Required Tasks to offer this

  • non-indirect table mode support (needs test and debug)

  • split virtio PCI device framework and virtio-net driver

  • SMP support


If you're interested in development of virtio drivers in FreeBSD, please
contact me. I'm not a good kernel-hacker (actually this is my first
work for kernel mode program and also my first C work), so any help are
welcome.

vm162# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
        ether 52:54:00:1f:61:0d
        inet 192.168.44.162 netmask 0xfffffe00 broadcast 192.168.45.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

vm162# make load
/sbin/kldload -v /usr/src/sys/dev/xen/virtio/virtio_pci.ko
virtio_pci0: <virtio-net Virtual Network Interface> port 0xcb00-0xcb1f mem 0xf2054000-0xf2054fff irq 11 at device 8.0 on pci0
virtio_pci0: assigning PCI resouces: <1>mem <0>ioport <0>irq callback
virtio_pci0: [GIANT-LOCKED]
virtio_pci0: [ITHREAD]
vn0: Ethernet address: 52:54:00:1f:61:0e
Loaded /usr/src/sys/dev/xen/virtio/virtio_pci.ko, id=2

vm162# ifconfig vn0 up
vm162# ifconfig vn0 192.168.90.1 255.255.255.0
vm162# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
        ether 52:54:00:1f:61:0d
        inet 192.168.44.162 netmask 0xfffffe00 broadcast 192.168.45.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
vn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 52:54:00:1f:61:0e
        inet 192.168.90.1 netmask 0xffffff00 broadcast 255.255.255.0

vm162# ping 192.168.90.2
PING 192.168.90.2 (192.168.90.2): 56 data bytes
64 bytes from 192.168.90.2: icmp_seq=0 ttl=64 time=3.696 ms
64 bytes from 192.168.90.2: icmp_seq=1 ttl=64 time=1.004 ms
64 bytes from 192.168.90.2: icmp_seq=2 ttl=64 time=1.051 ms
64 bytes from 192.168.90.2: icmp_seq=3 ttl=64 time=1.044 ms
64 bytes from 192.168.90.2: icmp_seq=4 ttl=64 time=1.218 ms
64 bytes from 192.168.90.2: icmp_seq=5 ttl=64 time=0.970 ms
^C
--- 192.168.90.2 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.970/1.497/3.696/0.986 ms

vm162# iperf -c 192.168.90.2
------------------------------------------------------------
Client connecting to 192.168.90.2, TCP port 5001
TCP window size: 32.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.90.1 port 15185 connected with 192.168.90.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.7 sec   142 MBytes   112 Mbits/sec
vm162#

performance comparison between fxp(e1000) and vn(virtio)


投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2010年10月12日火曜日

FreeBSD用virtioドライバを作ってみた

なんとなくノリで「virtioのドライバを書いてみたくなった」ので9月末から作業を開始したのですが、この週末で大体動くようになりました。


コードが整理できたら、FreeBSDソースツリーへのコミット目指して頑張ってみますかねぇ。まぁ、予定は未定です。また、実際にドライバが書ける程度まではvirtioを研究したので、また機会を見て情報共有できればと思っています。


■ どんなかんじ？



見てもらうのが早いですよね。こんなかんじ。

vm162# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
        ether 52:54:00:1f:61:0d
        inet 192.168.44.162 netmask 0xfffffe00 broadcast 192.168.45.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

vm162# make load
/sbin/kldload -v /usr/src/sys/dev/xen/virtio/virtio_pci.ko
virtio_pci0: <virtio-net Virtual Network Interface> port 0xcb00-0xcb1f mem 0xf2054000-0xf2054fff irq 11 at device 8.0 on pci0
virtio_pci0: assigning PCI resouces: <1>mem <0>ioport <0>irq callback
virtio_pci0: [GIANT-LOCKED]
virtio_pci0: [ITHREAD]
vn0: Ethernet address: 52:54:00:1f:61:0e
Loaded /usr/src/sys/dev/xen/virtio/virtio_pci.ko, id=2

vm162# ifconfig vn0 up
vm162# ifconfig vn0 192.168.90.1 255.255.255.0
vm162# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
        ether 52:54:00:1f:61:0d
        inet 192.168.44.162 netmask 0xfffffe00 broadcast 192.168.45.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
vn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 52:54:00:1f:61:0e
        inet 192.168.90.1 netmask 0xffffff00 broadcast 255.255.255.0

vm162# ping 192.168.90.2
PING 192.168.90.2 (192.168.90.2): 56 data bytes
64 bytes from 192.168.90.2: icmp_seq=0 ttl=64 time=3.696 ms
64 bytes from 192.168.90.2: icmp_seq=1 ttl=64 time=1.004 ms
64 bytes from 192.168.90.2: icmp_seq=2 ttl=64 time=1.051 ms
64 bytes from 192.168.90.2: icmp_seq=3 ttl=64 time=1.044 ms
64 bytes from 192.168.90.2: icmp_seq=4 ttl=64 time=1.218 ms
64 bytes from 192.168.90.2: icmp_seq=5 ttl=64 time=0.970 ms
^C
--- 192.168.90.2 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.970/1.497/3.696/0.986 ms

vm162# iperf -c 192.168.90.2
------------------------------------------------------------
Client connecting to 192.168.90.2, TCP port 5001
TCP window size: 32.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.90.1 port 15185 connected with 192.168.90.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.7 sec   142 MBytes   112 Mbits/sec
vm162#

■ ベンチマーク

非常にいい加減なベンチマークですが、デフォルト設定の e1000 エミュレーションより微妙に速いようです。





e1000 オフロードエンジン等を ON/OFF すると性能が変わるようなので、まぁだいたい同じぐらいのパフォーマンスが出ていると考えればよさそうです。

■ 実装状況


  • ロック皆無！たぶん……いや、間違いなく、SMPだと即死します。

  • virtio PCIインターフェイスとvirtio-netがまだ綺麗に分離できていない。

  • キャパビリティ (features bit)のほとんどは未実装

■ その他今後の課題


  • virtio デバイスを実装するためのフレームワーク検討

  • ハードウェア チェックサム、その他キャパビリティのサポート

  • 一部 GPL ライセンスされたコードが含まれるため除去

  • 安定性の向上

  • チューニング

■ 作業環境


  • Host: Fedora 14: Fedora release 14 (Branched) Alpha Release, x86_64

  • Guest: FreeBSD 8.1-RELEASE, amd64

投稿者 時刻: 1 件のコメント:
ラベル: , , ,

2010年9月23日木曜日

shadow_memory

　シャドウページテーブルのサイズ（MB）を指定します。明示的に指定しない場合
は必要な容量が自働確保されます。


■ ドメイン


  • 完全仮想化ドメイン(HVM)


■ 書式

shadow_memory=<n>


■ 必要なシャドウメモリの容量


  • 準仮想化ドメイン …… 不要

  • HVM ドメイン（x86、x86_64）…… 256 ×仮想CPU 数＋ 2 ×最大メモリ量（MB）ページ
    　　（1 ページ＝ 4KB）

  • HVM ドメイン（IA-64）…… 不要


■ 例

memory=1024
shadow_memory=8


■ 注意点


  • 本情報はXen 3.4.0時点の内容です



投稿者 時刻: 0 件のコメント:
ラベル: ,

xen_platform_pci

Xen プラットフォームPCI デバイスの有効・無効を指定します。本デバイスは、Xenのパラバーチャルドライバの利用するために必要です。

■ ドメイン


  • 完全仮想化ドメイン(HVM)


■ 書式

xen_platform_pci=<n>

■ <n>の値


  • 1 …… 有効

  • 0 …… 無効


■ 例

xen_platform_pci=1


■ 注意点


  • Xen プラットフォームPCI デバイスは、HVM ドメイン上のゲストOS がXen ハイパーバ
    イザと通信するために使用するものです。



投稿者 時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)