前回の日記を書いて、さらにtsutsuiさんからコメントを頂きました。
どうやら、昔のVIAチップの設計がイマイチで、それを回避するコードが入っていたそうです。
最近のVIAチップはそういう回避コードは不要になっているにもかかわらず、回避コードの下に慣習的に各々のVIA IDE個別の設定が追加されていったようです。
今回のケースではその回避コードが逆に悪さをしてうまく動いていないということですね。むしろ、最近のチップがちゃんと動いているのか心配になってしまいます。
じゃぁ、回避コードのルートに乗っかる前に、さっさと処理をしてしまえばよいということで、次のような修正を加えることにしました。
それでは、dbenchしてみましょう!
dbehcnの数字が60MB/s程度だとして、これが何を意味するのかは他の結果と比較してみなければなりませんが、とても乱暴にUDMA 4 (66MB/s) 相当の速度と仮置きしておくことにしましょう。
せっかくUDMAを0から6にしたのに効果は得られていないようです。おかしいですね。
仮説としては三つくらいでしょうか。
SATAコントローラがPATAコンパチモードで動くとUDMAの指定はともかく、そこそこの速度で動いてくれるという動作なのかもしれません。
じゃぁ、SATAで動かせばいいじゃないかという話になるのですが、実は試行錯誤をしていた段階で
三つ目の仮説であるdbenchどうなの、という話は確かにあって、ベンチマークプログラムの選択はなかなか奥が深いですね。
このようなディスクの話であればiozoneが良いのではないかとお勧めされたりしているのですが、iozoneのオプションを見て、そっと閉じる、という情けない状態だったりします。
いくつか宿題は残っていますが、一定の結論がでたのでsend-prに向けて準備を進めたいと思います。
どうやら、昔のVIAチップの設計がイマイチで、それを回避するコードが入っていたそうです。
最近のVIAチップはそういう回避コードは不要になっているにもかかわらず、回避コードの下に慣習的に各々のVIA IDE個別の設定が追加されていったようです。
今回のケースではその回避コードが逆に悪さをしてうまく動いていないということですね。むしろ、最近のチップがちゃんと動いているのか心配になってしまいます。
じゃぁ、回避コードのルートに乗っかる前に、さっさと処理をしてしまえばよいということで、次のような修正を加えることにしました。
--- ./sys/dev/pci/viaide.c.orig 2011-12-29 05:25:40.000000000 +0000
+++ ./sys/dev/pci/viaide.c 2012-03-10 12:43:07.00000000
@@ -464,6 +469,11 @@
interface = PCIIDE_INTERFACE_BUS_MASTER_DMA |
PCIIDE_INTERFACE_PCI(0) | PCIIDE_INTERFACE_PCI(1);
break;
+ case PCI_PRODUCT_VIATECH_VX900_IDE:
+ aprint_normal_dev(sc->sc_wdcdev.sc_atac.atac_dev,
+ "VIA Technologies VX900 ATA133 controller\n");
+ sc->sc_wdcdev.sc_atac.atac_udma_cap = 6;
+ break;
default:
/*
* get a PCI tag for the ISA bridge.
起動すると期待どおりのメッセージが表示されました。viaide0 at pci0 dev 15 function 0 viaide0: VIA Technologies VX900 ATA133 controller viaide0: bus-master DMA support present viaide0: primary channel configured to native-PCI mode viaide0: using ioapic0 pin 21 for native-PCI interrupt atabus0 at viaide0 channel 0 viaide0: secondary channel configured to native-PCI mode atabus1 at viaide0 channel 1やりましたね!
それでは、dbenchしてみましょう!
Throughput 60.1017 MB/sec 5 procsあれ?! おかしいな。もう一回。
Throughput 62.8053 MB/sec 5 procsおっ! 先ほどよりは良くなりましたね。って言っても前回の不完全パッチでも
Throughput 63.8846 MB/sec 5 procsということで、数値的にはほとんど変わらないという結果になりました。
dbehcnの数字が60MB/s程度だとして、これが何を意味するのかは他の結果と比較してみなければなりませんが、とても乱暴にUDMA 4 (66MB/s) 相当の速度と仮置きしておくことにしましょう。
せっかくUDMAを0から6にしたのに効果は得られていないようです。おかしいですね。
仮説としては三つくらいでしょうか。
- 不完全パッチでもUDMA 0ではなくUDMA 4相当が使われていた
- 今回の修正でもまだ不十分でUDMA 4相当で動いている
- 実はちゃんと動いているけどdbenchがかけるワークロードではUDMAの差が数字として現れない
SATAコントローラがPATAコンパチモードで動くとUDMAの指定はともかく、そこそこの速度で動いてくれるという動作なのかもしれません。
じゃぁ、SATAで動かせばいいじゃないかという話になるのですが、実は試行錯誤をしていた段階で
{ PCI_PRODUCT_VIATECH_VX900_IDE,
0,
NULL,
via_chip_map,
},
のところを
via_sata_chip_map_7,
にして動かしてみたのですが、起動時にpanicしてそれ以降深く追っかけていなかったのです。せっかくのSATAコントローラなのですからSATAで動かしたいものですね。三つ目の仮説であるdbenchどうなの、という話は確かにあって、ベンチマークプログラムの選択はなかなか奥が深いですね。
このようなディスクの話であればiozoneが良いのではないかとお勧めされたりしているのですが、iozoneのオプションを見て、そっと閉じる、という情けない状態だったりします。
いくつか宿題は残っていますが、一定の結論がでたのでsend-prに向けて準備を進めたいと思います。
1: tsutsui 『dmesgのドライブ側の行で wd0: drive supports PIO mode 4, DMA mode 2, Ultra...』 (2012/03/10 15:53)