Ottawa Linux Symposium2日目リポート(3/3 ページ)

» 2005年07月27日 16時44分 公開
[David-'cdlu'-Graham,japan.linux.com]
前のページへ 1|2|3       

e1000はいかが

 Intelのジョン・ロンシャック(John A. Ronciak)氏が、「ネットワークドライバのパフォーマンスと測定:e1000の事例研究」という題で講演をした。この事例研究でRonciakが目指したものは、カーネル2.6のもとでe1000ギガビットイーサネットチップのパフォーマンスを向上させることである。

 調べてみると、カーネル2.4でのチップパフォーマンスのほうがカーネル2.6でのパフォーマンスより高い。設定を変えながら何度テストしても、結果は同じだった。カーネル2.6には改良の余地がある、というのが同氏の結論だ。

 かつて、32ビットの33MHz PCIバスに10/100ネットワークインタフェースカードを差すだけで、入出力の過負荷が起こり、システムがダウンすることがあった。今日、最新のマザーボードで同じことをやろうとすれば、10ギガビットのイーサネットデバイスが必要だという。

 Linuxには、プラットフォームやオペレーティングシステムを問わずに使えるまともなパフォーマンスデータ生成ユーティリティがない。「リンゴをリンゴと比べられない」のが難点だ、とロンシャック氏は言う。とりあえず、IXIAのChariotというプログラムをテストツールとして使い、それで集めたというデータが出席者に示された。

 それによると、データスループットパフォーマンスでは常にカーネル2.4が2.6を上回っていた。同じカーネル内では(2.4でも2.6でも)、バージョンによってパフォーマンスに大きなばらつきがあった。また、カーネルの設定オプションがNAPIかUPかでも大きな変化が見られた。

 ロンシャック氏によると、NAPIはネットワークパフォーマンス改善のためによく使われるインタフェースで、カーネル2.4でNAPIを使用すると、小さなCPU使用量で同じスループットを実現できる、と言う。ところが、ロンシャック氏の得たデータでは、同カーネル・同スループットという条件なのに、NAPI使用時のCPU使用量のほうがNAPI不使用時のCPU使用量より大きくなった。

 パフォーマンスの測定ではフレームサイズが重要だ、とロンシャック氏は言う。フレームが大きければ、パケットで出ていくデータは十分に測定可能な量になる。だが、パケットが小さいときは、接続を通過するデータの実際量よりパケット数を測定したほうがよいかもしれない。スライドでは、この点が分かりやすく示されていた。

 同氏が行った初期のテストでは、NAPIを使用することでパケット損がむしろ増えたが、NAPI加重値を加減することでパケット損を減らすことができた。問題は、入力バッファのクリア速度がデータの着信速度に追いつかないことだ、とRonciakは説明する。そのために発生するパケット損であり、この問題を解決するにはドライバの変更が必要だろう。場合によっては修正可能なNAPI加重システムなどが有効だろうが、この問題についてはさらに検討が必要である。

 NAPIの問題点はほかにもある。たとえば、NAPIによるインタフェースポーリング(新しいデータがカーネルを待っているかどうかの調査)の速度が、インタフェースによる着信要求処理の速度を超えることである。このためシステムリソースの無駄遣いが生じ、動作効率が低下する。この問題の解決方法として同氏が提案するのは、ネットワークインタフェースの速度に合わせた最小限のポーリング遅延である。

 今回の調査で1つ学んだことは、怖がらず、コミュニティーにどんどん助けを求めることだ、と同氏は話す。コミュニティーに呼びかけることで、テスト自体が簡単に運んだし、バグ修正やパッチや改良点のコーディングも容易だった。これだけは声を大にして伝えておきたい、と話していた。そして、これからもLinuxにおけるネットワークパフォーマンスの向上に取り組んでいきたいし、NAPIの改善にも努力したい、と結び、ぜひ協力を、と呼びかけていた。

 プレゼンテーションの最後にロンシャック氏が繰り返したことは、プラットフォームを選ばないフリーで標準的な測定ツールの必要性である。ネットワークパフォーマンスのボトルネックを新しいハードウェア機能で解決できないか、とも考えているので、ぜひ手助けを、と言っていた。

夜のBOFセッションで

 夜のBOFセッションでは、国家安全保障局(NSA)のステファン・スモーリー(Stephen Smalley)氏がNSAのSELinuxカーネルについてその現状などを語った。

 SELinuxにとって昨年は重要な年だった、とスモーリー氏は言う。SELinux自体は、1年前のFedora Core 2リリースにすでに含まれていたが、デフォルトでは無効だった。だが、Fedora Core 3とFedora Core 4では、SELinuxが含まれるだけでなく、デフォルトで有効に(有効状態で出荷されるように)なった。

 また、スケーラブルになり、大規模なマルチプロセッサシステムにも適合するようになった。現在、IBMがSELinuxの評価を進めており、いずれ米国政府による使用も正式に認められるかもしれない。

 SELinuxでは、複数カテゴリにまたがるセキュリティシステムの可能性が探られていて、システムのセキュリティポリシーに対するユーザーの参加度が高まる、とスモーリー氏は言う。

 2006年3月に、メリーランド州ボルチモアでSELinuxシンポジウムが開かれる。SELinuxの実像を探るにはよい機会となるだろう。

前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ