ハイパー・スレッド処理でLinuxを高速化

シングル・プロセッサーでマルチプロセッサー並みの性能を実現

IntelのXeonプロセッサーにハイパー・スレッド処理 (HT: Hyper-Threading) という新しいテクノロジーが導入されました。オペレーティング・システムから見て、1個のプロセッサーが2個の論理プロセッサーの振る舞いをするように見せるテクノロジーです。このテクノロジーを有効にすると、Xeonプロセッサーは、それぞれのプロセッサーで同時に並行して複数のスレッドを実行できるようになり、性能を格段に向上させることができます。われわれは、どの程度の性能向上が望めるのかを数量化することにしました。

バージョン2.4および2.5に採用されている現在のLinuxの対称マルチプロセシング (SMP) カーネルは、ハイパー・スレッド処理を考慮して設計されており、マルチスレッド型のベンチマークでは、性能の向上が観測されています (これについての詳細を紹介している記事については、稿末の参考文献を参照してください)。

本稿では、Linux SMPカーネルに対するハイパー・スレッド処理 (HT) の効果についてのわれわれの調査結果を紹介します。ハイパー・スレッド処理対応のLinux SMPカーネルの性能を、この機能に非対応なカーネルのものと比較します。テストされたシステムは、マルチスレッド処理が可能なシングルCPUのXeonです。今回の調査では、カーネルの中でも、ハイパー・スレッド処理の影響を受ける可能性のある部分、すなわちスケジューラー、低レベルのカーネル・プリミティブ、ファイル・サーバー、ネットワーク、スレッドのサポートなどを対象とするベンチマークを使用しました。

Linuxカーネル2.4.19での結果からは、ハイパー・スレッド処理テクノロジーがマルチスレッド型アプリケーションの性能を30%向上させうることが示されます。現在Linuxカーネル2.5.32に対する変更作業が進められており、それによって、速度性能は51%も向上する可能性があります。

はじめに

Intelのハイパー・スレッド処理テクノロジーとは、IntelのNetBurstマイクロアーキテクチャー・パイプライン内の資源を複製、区分け (partition)、共有することで、物理的には1個のプロセッサーで2個の論理プロセッサーを実現するものです。

資源の複製では、2個のスレッドをサポートするために、以下の資源がコピーされます。

  • CPUごとのアーキテクチャー上のすべての状態
  • 命令ポインター、名前変更ロジック
  • いくつかの、もっと小さな資源 (リターン・スタック・プレディクターやITLBなど)

資源の区分けでは、実行中のスレッドの間で以下の資源を分割します。

  • 各種バッファー (並べ換えバッファー、ロード/ストア・バッファー、キューなど)

資源の共有では、実行中の2個のスレッドの間で、必要に応じて、以下の資源を利用します。

  • アウト・オブ・オーダー実行エンジン
  • キャッシュ

通常、物理プロセッサーは、それぞれ1個のプロセッサー・コアに1個のアーキテクチャー状態を保持しながら、スレッドへのサービスを行います。HTでは、それぞれの物理プロセッサーが、1個のコアに2個のアーキテクチャー状態を保持することで、それを2個の論理プロセッサーに見せながら、スレッドへのサービスを行います。システムBIOSは、物理プロセッサーのそれぞれのアーキテクチャー状態を個々に記録・管理 (enumerate) します。ハイパー・スレッド処理対応のオペレーティング・システムは、論理プロセッサーを利用しますので、2倍の資源を保持しながら、スレッドへのサービスを行うことになります。


Xeonプロセッサーでのハイパー・スレッド処理のサポート

Xeonは、汎用プロセッサーとして同時多重スレッド処理 (SMT: Simultaneous Multi-Threading) を実装した最初のプロセッサーです (プロセッサー・ファミリーXeonの詳細については、参考文献を参照してください)。1個の物理プロセッサーで2個のスレッドを実行するという目的を達成するために、Xeonは、複数のスレッドのコンテキストを同時に管理し、スケジューラーが基本的に独立な2個のスレッドを並行してディスパッチできるようにします。

オペレーティング・システム (OS) は、SMPシステムで行うように、コード・スレッドを各論理プロセッサーにスケジュールし、ディスパッチします。スレッドがディスパッチされない場合には、それに対応する論理プロセッサーはアイドル状態にされます。

スレッドが、論理プロセッサーLP0にスケジュールされ、ディスパッチされる場合、ハイパー・スレッド処理テクノロジーは、そのスレッドを実行するために必要なプロセッサー資源を利用します。

2個目のスレッドが2つ目の論理プロセッサーLP1にスケジュールされ、ディスパッチされると、その2個目のスレッドを実行するために必要な資源が複製、分割、共有されます。各プロセッサーは、パイプライン内の各ポイントで、スレッドの制御と処理を行うためのいろいろな選択を行います。スレッドが終了すると、オペレーティング・システムは、使用されていないプロセッサーをアイドル状態にし、資源を解放して、実行中のプロセッサーがそれを利用できるようにします。

OSは、デュアル・プロセッサー・システムやマルチ・プロセッサー・システムで行うように、スレッドを各論理プロセッサーにスケジュールし、ディスパッチします。システムがスレッドをスケジュールして、パイプラインに送り込むと、2個のスレッドを処理するために必要な資源が利用されます。


Linuxカーネル2.4におけるハイパー・スレッド処理のサポート

Linuxカーネルの下では、2個の仮想的なプロセッサーを備えたハイパー・スレッド処理プロセッサーは、本当の物理プロセッサーが1対存在するかのように扱われます。したがって、SMPをサポートするスケジューラーは、ハイパー・スレッド処理もサポートできるはずです。Linuxカーネル2.4.xがハイパー・スレッド処理をサポートするようになったのは2.4.17からで、以下の機能拡張を行っています。

  • 128バイトのロック・アラインメント
  • スピン・ウェイト・ループ最適化
  • 非実行ベースの遅延ループ
  • ハイパー・スレッド処理対応プロセッサーの検出、およびSMPマシンとして論理プロセッサーを始動する機能
  • MTRRのシリアライゼーションとマイクロコード更新ドライバー (共有される状態に影響を及ぼす機能)
  • システムがアイドル状態にあるときに、論理プロセッサーのスケジューリングよりも物理プロセッサーのスケジューリングを優先させるためのスケジューラーの最適化
  • 64Kのエイリアシングを回避するためのオフセット・ユーザー・スタック

カーネル性能の測定

Linuxカーネルでのハイパー・スレッド処理の効果を評価するために、HT対応のIntel Xeonプロセッサーを搭載するシステムで、カーネルのベンチマーク性能を測定してみました。ハードウェアは、SMT機能搭載の1.6 GHz Xeon MPプロセッサーのシングルCPU、2.5 GBのRAM、および9.2 GBのSCSIディスク・ドライブ2基としました。測定に使用したカーネルは、標準的なバージョン2.4.19で、SMPが有効になるように構成、構築したものです。カーネルによるハイパー・スレッド処理のサポートは、ブート・オプションで指定しました。ハイパー・スレッド処理を有効にするときにはacpismp=force とし、ハイパー・スレッド処理を無効にするときにはnoht としました。ハイパー・スレッド処理をサポートしているかどうかは、cat /proc/cpuinfo コマンドを使って調べることができ、サポートしていれば、このコマンドは、プロセッサー0とプロセッサー1の2個のプロセッサーを表示します。リスト1 のCPU 0と1にht フラグが立っていることに注意してください。ハイパー・スレッド処理がサポートされていない場合には、プロセッサー0のデータだけが表示されます。

リスト1. ハイパー・スレッド処理をサポートしていることを示すcat /proc/cpuinfoの出力
   processor    : 0
   vendor_id    : GenuineIntel
   cpu family   : 15
   model        : 1
   model name   : Intel(R) Genuine CPU 1.60GHz
   stepping     : 1
   cpu MHz      : 1600.382
   cache size   : 256 KB
   . . .
   fpu          : yes
   fpu_exception: yes
   cpuid level  : 2
   wp           : yes
   flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
   pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht
   tm
   bogomips     : 3191.60
   processor    : 1
   vendor_id    : GenuineIntel
   cpu family   : 15
   model        : 1
   model name   : Intel(R) Genuine CPU 1.60GHz
   stepping     : 1
   cpu MHz      : 1600.382
   cache size   : 256 KB
   . . . . .
   fpu          : yes
   fpu_exception: yes
   cpuid level  : 2
   wp           : yes
   flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
   pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht
   tm
   bogomips     : 3198.15

Linuxカーネルのベンチマーク

Linuxカーネルの性能を測定するために、LMbench、AIM Benchmark Suite IX (AIM9)、chat、dbench、およびtbenchの5種類のベンチマークを使用しました。LMbenchベンチマークは、基本的なシステム・コール、コンテキスト・スイッチングの待ち時間、メモリーのバンド幅など、さまざまなLinuxアプリケーション・プログラミング・インターフェース (API) の時間計測を行います。AIM9ベンチマークは、ユーザー・アプリケーションのワークロードを測定します。chatベンチマークは、チャット・ルームにならってモデル化されたクライアント/サーバーのワークロードです。dbenchベンチマークは、ファイル・サーバーのワークロード、tbenchは、TCPのワークロードです。Chat、dbench、tbenchはマルチスレッド型のベンチマークであり、それ以外はシングル・スレッド型のベンチマークです。


LinuxのAPIに対するハイパー・スレッド処理の効果

LinuxのAPIに対するハイパー・スレッド処理の効果は、LMbenchで測定しました。これは、バンド幅と待ち時間を測定するテスト・スイートからなるマイクロベンチマークです。この中には、キャッシュ経由のファイル読み出し、メモリー・コピー (bcopy)、メモリーの読み書き (および待ち時間)、パイプ、コンテキスト・スイッチング、ネットワーク処理、ファイルシステムの作成と削除、プロセス生成、シグナル処理、およびプロセッサー・クロックの待ち時間が含まれます。LMbenchは、スケジューラー、プロセス管理、通信、ネットワーク処理、メモリー・マップおよびファイルシステムといったカーネル・コンポーネントの性能を調べるためのものです。低レベルのカーネル・プリミティブは、その下部にあるハードウェアの機能や性能を示す良い指標となります。

ハイパー・スレッド処理の効果を調べるために、メッセージ制御にかかる時間 (すなわち、システムがある命令をどの程度高速に実行できるか) を表す待ち時間の測定値に焦点を当てました。待ち時間は、命令ごとにマイクロ秒単位で示されます。

表1は、LMbenchでテストされたカーネル機能の一部を示したものです。各データ値は、3回の実行結果を平均したものです。データは、収斂し、同じテスト環境で実行された場合に再現可能なものであることを保証できるかどうかがテストされました。一般に、これらの機能がシングル・スレッドとして実行される場合、ハイパー・スレッド処理を有効にしたときと無効にしたときとで性能に差はありません。しかし、パイプの待ち時間のテストやプロセス待ち時間の3つのテストなど、スレッドを2個実行しなければならない場合には、ハイパー・スレッド処理を有効にすると、待ち時間の性能が低下するようです。ここでは、SMPが有効となるように構成された標準カーネルを2419sで表しています。ハイパー・スレッド処理をサポートしない構成にしたカーネルは、2419s-nohtで表しています。ハイパー・スレッド処理をサポートしているカーネルは、2419s-htと表しています。

表1. LinuxのAPIに対するハイパー・スレッド処理の効果
カーネルの機能2419s-noht2419s-ht速度の向上
単純なsyscall1.101.100%
単純なread1.491.490%
単純なwrite1.401.400%
単純なstat5.125.140%
単純なfstat1.501.500%
単純なopen/close7.387.380%
10個のfdの中からの選択5.415.410%
10個のtcp fdの中からの選択5.695.700%
シグナル・ハンドラーのインストール1.561.550%
シグナル・ハンドラーのオーバーヘッド4.294.270%
パイプの待ち時間11.1611.31-1%
プロセスのfork+exit190.75198.84-4%
プロセスのfork+execve581.55617.11-6%
プロセスのfork+/bin/sh -c3051.283118.08-2%

注意: データの単位はマイクロ秒。小さい値ほど性能が良いことを意味する。

パイプの待ち時間テストは、UNIXのパイプを介して通信を行う2個のプロセスを使用して、ソケット経由でのプロセス間通信の待ち時間を測定します。このベンチマークは、2個のプロセスの間でトークンをやりとりします。性能の低下は1%で、無視できるほどのものです。

3つのプロセス・テストでは、Linux下でのプロセスの生成と実行が行われます。これは、基本的な実験用スレッドを生成するのに要する時間を測定するためのテストです。プロセスのfork+exitのテストのデータは、1個のプロセスを2個の (ほとんど) 同一のコピーに分割し、一方を終了させるのに要する待ち時間を表します。これは、新しいプロセスを生成するための方法ですが、両方のプロセスが同じことを行うわけですから、あまり有用な方法とは言えません。このテストでは、ハイパー・スレッド処理は、性能を4%低下させています。

プロセスのfork+execveのデータは、新しいプロセスを生成し、その新しいプロセスで新しいプログラムを実行させるのに要する時間を表します。これは、すべてのシェル (コマンド・インタープリター) の内部ループで行われていることです。このテストでは、ハイパー・スレッド処理を有効にすることで、性能が6%低下しています。

プロセスのfork+/bin/sh -cのテストのデータは、新しいプロセスを生成し、その新しいプロセスで新しいプログラムを実行させるときに、システム・シェルにプログラムを見つけ出させて実行させる場合に要する時間を表します。これは、systemというCのライブラリー・インターフェースが実装している方法です。これは、最も一般的に利用されている呼び出しであるとともに、最も高価な呼び出しでもあります。ハイパー・スレッド処理を有効にした場合、無効にした場合に比べ、このテストの実行速度は、2%遅くなります。


Linuxのシングル・ユーザー・アプリケーション・ワークロードに対するハイパー・スレッド処理の効果

ベンチマークAIM9は、ハードウェアとオペレーティング・システムの性能を測定するために設計されたシングル・ユーザーのワークロードです。結果は、表2のとおりです。このベンチマークのテストは、各種の同期的ファイル操作と整数のふるい分け (Integer Sieves) を除き、ほとんどが、ハイパー・スレッド処理を有効にしたときと無効にしたときとで、同じ性能を示しました。ランダムな同期的ディスク書き込み (Sync Random Disk Writes)、シーケンシャルな同期的ディスク書き込み (Sync Sequential Disk Writes)、および同期的ディスク・コピー (Sync Disk Copies) の3つの操作は、ハイパー・スレッド処理を有効にした場合、約35%遅くなっています。他方、整数のふるい分けでは、ハイパー・スレッド処理を有効にしたときのほうが、無効にしたときよりも速度を60%向上させています。

表2. AIM9のワークロードに対するハイパー・スレッド処理の効果
2419s-noht2419s-ht速度の向上
add_double1秒あたりの倍精度加算の回数 (単位は1,000回)6383616377240%
add_float1秒あたりの単精度加算の回数 (単位は1,000回)6384006377620%
add_long1秒あたりの長整数 (Long Integer) 加算の回数 (単位は1,000回)147904114790410%
add_int1秒あたりの整数 (Integer) 加算の回数 (単位は1,000回)148354914910171%
add_short1秒あたりの短整数 (Short Integer) 加算の回数 (単位は1,000回)148080014784000%
creat-clo1秒あたりのファイルの生成/クローズの回数1291001397008%
page_test1秒あたりのSystem Allocations & Pagesの回数1613301618400%
brk_test1秒あたりのシステム・メモリー割り当て (System Memory Allocations) の回数6334666358000%
jmp_test1秒あたりのローカルでないgotoの回数866690086948000%
signal_test1秒あたりのシグナル・トラップの回数1423001429000%
exec_test1秒あたりのプログラム・ロードの回数3873870%
fork_test1秒あたりのタスク生成回数236524473%
link_test1秒あたりのLink/Unlink対 (つい) の回数54142591699%
disk_rr1秒あたりのランダムなディスク読み出しの回数 (K)85758895104%
disk_rw1秒あたりのランダムなディスク書き込みの回数 (K)76800784552%
disk_rd1秒あたりのシーケンシャルなディスク読み出しの回数 (K)3519043568641%
disk_wrt1秒あたりのシーケンシャルなディスク書き込みの回数 (K)1541121563591%
disk_cp1秒あたりののディスク・コピーの回数 (K)1043431062832%
sync_disk_rw1秒あたりのランダムな同期的ディスク書き込みの回数 (K)239155-35%
sync_disk_wrt1秒あたりのシーケンシャルな同期的ディスク書き込みの回数 (K)9760-38%
sync_disk_cp1秒あたりの同期的ディスク・コピーの回数 (K)9760-38%
disk_src1秒あたりのディレクトリー検索の回数4891548195-1%
div_double1秒あたりの倍精度除算の回数 (単位は1,000回)37162372020%
div_float1秒あたりの単精度除算の回数 (単位は1,000回)37125372020%
div_long1秒あたりの長整数 (Long Integer) 除算の回数 (単位は1,000回)27305273600%
div_int1秒あたりの整数 (Integer) 除算の回数 (単位は1,000回)27305273320%
div_short1秒あたりの短整数 (Short Integer) 除算の回数 (単位は1,000回)27305273600%
fun_cal1秒あたりのの関数呼び出し (引数なし) の回数3033126830105600-1%
fun_cal11秒あたりの関数呼び出し (引数1個) の回数1124352001128448000%
fun_cal21秒あたりの関数呼び出し (引数2個) の回数97587200978432000%
fun_cal151秒あたりの関数呼び出し (引数15個) の回数44748800448000000%
sieve1秒あたりの整数ふるい分け (Integer Sieves) の回数152460%
mul_double1秒あたりの倍精度乗算の回数 (単位は1,000回)4562874567430%
mul_float1秒あたりの単精度乗算の回数 (単位は1,000回)4560004567430%
mul_long1秒あたりの長整数 (Long Integer) 乗算の回数 (単位は1,000回)1679041681680%
mul_int1秒あたりの整数 (Integer) 乗算の回数 (単位は1,000回)1679761682160%
mul_short1秒あたりの短整数 (Short Integer) 乗算の回数 (単位は1,000回)1557301559100%
num_rtns_11秒あたりの数値関数の回数92740929200%
trig_rtns1秒あたりの三角関数の回数4040004050000%
matrix_rtns1秒あたりの点変換 (Point Transformations) の回数8751408913002%
array_rtns1秒あたりの解の得られた線型システム (Linear Systems Solved) の個数5795780%
string_rtns1秒あたりの文字列操作の回数256025640%
mem_rtns_11秒あたりの動的メモリー操作の回数9820359800190%
mem_rtns_21秒あたりのブロック・メモリー操作の回数2145902153900%
sort_rtns_11秒あたりの並べ換え処理の回数481472-2%
misc_rtns_11秒あたりの補助ループ (Auxiliary Loops) の回数79167864-1%
dir_rtns_11秒あたりのディレクトリー操作の回数200200020010000%
shell_rtns_11秒あたりのシェル・スクリプト数95972%
shell_rtns_21秒あたりのシェル・スクリプト数95961%
shell_rtns_31秒あたりのシェル・スクリプト数95972%
series_11秒あたりの級数計算 (Series Evaluations) の回数316527031896301%
shared_memory1秒あたりの共有メモリー操作の回数1740801742200%
tcp_test1秒あたりのTCP/IPメッセージ数65835662311%
udp_test1秒あたりのUDP/IPデータグラム数1118801121500%
fifo_test1秒あたりのFIFOメッセージ数2289202289000%
stream_pipe1秒あたりのストリーム・パイプ・メッセージ数1702101710600%
dgram_pipe1秒あたりのデータグラム・パイプ・メッセージ数1683101705601%
pipe_cpy1秒あたりのパイプ・メッセージ数245090243440-1%
ram_copy1秒あたりのメモリー間コピー4900267084924786681%

Linuxのマルチスレッド型アプリケーション・ワークロードに対するハイパー・スレッド処理の効果

Linuxのマルチスレッド型アプリケーションに対するハイパー・スレッド処理の効果を測定するためには、チャット・ルームにならってモデル化されたchatベンチマークを使用します。このベンチマークには、クライアントとサーバーの両方が関係してきます。ベンチマークのクライアント側は、1秒あたりに送られてくるメッセージの数を報告します。チャット・ルームとメッセージの数によってワークロードが制御されます。このワークロードは、大量のスレッドとTCP/IP接続を生成し、大量のメッセージを送受信します。デフォルトのパラメーターは、以下のとおりです。

  • チャット・ルームの数 = 10
  • メッセージの数 = 100
  • メッセージのサイズ = 100バイト
  • ユーザーの数 = 20

デフォルトでは、各チャット・ルームのユーザー数は20人です。全部でチャット・ルームの数は10ですので、ユーザー数は20x10 = 200人になります。チャット・ルームのユーザーそれぞれについて、クライアントがサーバーに接続します。ユーザー数は200ですので、サーバーへの接続数は200になります。チャット・ルームの各ユーザー (すなわち、接続) について、「送信」スレッドと「受信」スレッドが生成されますので、チャット・ルーム数が10の場合、10x20x2 = 400個のクライアント・スレッドと400個のサーバー・スレッドが生成されることになり、合計で800個のスレッドが生成されることになります。それだけではありません。

各クライアントの「送信」スレッドは、指定された数のメッセージをサーバーに送信します。チャット・ルーム数が10で、メッセージ数が100の場合、クライアントは、10x20x100 = 20,000個のメッセージを送信することになります。サーバーの「受信」スレッドは、それと同じ数のメッセージを受信することになります。チャット・ルームのサーバーは、それら1個1個のメッセージを、同じチャット・ルームの他のユーザーにエコー・バックします。したがって、チャット・ルーム数10、メッセージ数100の場合、サーバーの「送信」スレッドは、10x20x100x19すなわち380,000個のメッセージを送信することになります。クライアントの「受信」スレッドは、それと同じ数のメッセージを受信することになります。

テストは、コマンド・ライン・セッションでチャット・サーバーを始動し、また別のコマンド・ライン・セッションでクライアントを始動することで、開始されます。クライアントがワークロードをシミュレートし、その結果は、クライアントから送信されたメッセージの数を表します。クライアントがテストを終了すると、サーバーはループし、クライアントからの別の開始メッセージを受け付けます。今回の測定では、チャット・ルームの数を20、30、40、50にしてベンチマークを実行しました。表3には、それに対応する接続数およびスレッド数を示してあります。

表3. テストされたチャット・ルーム数およびスレッド数
チャット・ルームの数接続の数スレッドの数送信されたメッセージの数受信されたメッセージの数メッセージの総数
204001,60040,000760,000800,000
306002,40060,0001,140,0001,200,000
408003,20080,0001,520,0001,600,000
5010004,000100,0001,900,0002,000,000

表4は、chatのワークロードに対するハイパー・スレッド処理による性能的効果を示しています。各データ値は、5回の実行の幾何平均を表しています。これらのデータから、チャット・ルームの数によって違いはありますが、ハイパー・スレッド処理がワークロードのスループットを22%から28%向上させていることがはっきりとわかります。全体として、ハイパー・スレッド処理は、4通りのチャット・ルーム数のサンプルの幾何平均で、チャット性能を24%を向上させています。

表4. チャットのスループットに対するハイパー・スレッド処理の効果
チャット・ルームの数2419s-noht2419s-ht速度の向上
20164,071202,80924%
30151,530184,80322%
40140,301171,18722%
50123,842158,54328%
幾何平均144,167178,58924%

注意: データは、クライアントから送信されたメッセージ数: 大きい値ほど性能が良いことを意味する。

図 1. チャットのワークロードに対するハイパー・スレッド処理の効果

Linuxのマルチスレッド型ファイル・サーバー・ワークロードに対するハイパー・スレッド処理の効果

ファイル・サーバーに対するハイパー・スレッド処理の効果は、dbenchおよびそれと同類のテストtbenchで測定しました。dbenchは、Ziff-Davis Mediaベンチマーク・プログラムに含まれている、よく知られているNetBenchベンチマークと同様のテストで、クライアントからのネットワーク・ファイル・リクエストを処理する場合のファイル・サーバーの性能を測定するためのものです。ただし、NetBenchが実際の物理的なクライアントを綿密にセットアップする必要があるのに対して、dbenchは、client.txtという4 Mバイトのファイルを見つけ出し、通常NetBenchクライアントで実行される命令90,000個ぶんのワークロードを発生させることで、それをシミュレートします。このファイルには、SMBopenx、SMBclose、SMBwritebraw、SMBgetatrなどのファイル操作指令が書き込まれています。これらのI/O呼び出しは、SAMBAのSMBDサーバーがnetbenchの実行の際に発生させるServer Message Protocol Block (SMB) に対応しています。SMBプロトコルは、Microsoft Windows 3.11、NTおよび95/98で、ディスクやプリンターを共有するために使用されているものです。

われわれのテストでは、ファイルのオープン、読み出し、書き込み、ロック、アンロック、ファイル属性の取得、ファイル属性の設定、クローズ、ディスクの空きスペースの獲得、ファイルの時刻の取得、ファイルの時刻の設定、検索オープン (find open)、次の検索 (find next)、検索クローズ (find close)、ファイル名の変更、ファイルの削除、ファイルの新規作成、ファイル・バッファーのフラッシュの合計18種類のI/O呼び出しを使用しました。

dbenchでは、物理的なセットアップに手間をかけることなく、任意の数のクライアントをシミュレートすることができます。dbenchは、ファイルシステムの負荷を発生させるだけで、ネットワーク呼び出しを行うことはありません。実行中、各クライアントは、転送されたデータのバイト数を記録し、この値をデータの転送に要した時間で割った値を求めます。そして、すべてのクライアントのスループット得点を合計し、サーバーの全体的なスループットを決定します。全体的なI/Oのスループット得点は、テスト中に転送された1秒あたりのMバイト数を表します。これは、サーバーがクライアントからのファイル・リクエストをどれだけ効率よく処理できるかの測定値となります。

dbenchは、CPUおよびI/Oスケジューラーに対して高い負荷と処理量を生成しますので、ハイパー・スレッド処理を評価するのに適したテストです。dbenchでは、クライアントによって数多くのファイルが同時に作成されたり、アクセスされますので、マルチスレッド型ファイル・サーバー機能をサポートするハイパー・スレッド処理の能力が厳格にテストされます。各クライアントは、約21 Mバイトぶんのテスト・データ・ファイルを作成します。クライアント数が20のテスト・ランでは、約420 Mバイトのデータが作成されることになります。dbenchは、Linuxのファイルシステムで使用されているエレベーター・アルゴリズムの性能を測定するのに適したテストだと考えることができます。dbenchは、このアルゴリズムの稼働時の有効性およびエレベーターが充分強力な働きをしているかどうかをテストするために使用されます。また、ページ交換 (page replacement) の性能を調べるのにも面白いテストです。

表5は、dbenchのワークロードに対するHTの効果を示しています。各データ値は、5回の実行の幾何平均を表しています。これらのデータから、ハイパー・スレッド処理が、dbenchの性能を最低9%、最大29%改善していることがわかります。全体的な改善は、5回のテストの幾何平均で18%です。

表 5. dbenchのスループットに対するハイパー・スレッド処理の効果
クライアントの数2419s-noht2419s-ht速度の向上
20132.82171.2329%
30131.43169.5529%
60119.95133.7712%
90111.89121.819%
12099.31114.9216%
幾何平均118.4140.318%

注意: データは、Mバイト/秒を単位としてのスループット: 大きい値ほど性能が良いことを意味する。

図 2. dbenchのワークロードに対するハイパー・スレッド処理の効果

tbench

tbenchも、dbenchと同様のファイル・サーバーのワークロードです。ただし、tbenchが発生させるのは、TCPとプロセスの負荷だけです。tbenchは、netbenchの負荷でSMBDが行うのと同じソケット呼び出しを行いますが、tbenchは、ファイルシステムの呼び出しは行いません。tbenchの思想は、SMBDのコードを高速化できることが前提であるかのように、netbenchのテストからSMBDを省くことにあります。tbenchのスループットの結果は、ファイルシステムI/OやSMBパケット処理をすべて省いてやると、netbenchの実行がいかに高速になるかを示しています。tbenchは、dbenchパッケージの一部として構築されています。

表6は、tbenchのワークロードに対するハイパー・スレッド処理の効果を示しています。先と同様、各データ値は、5回の実行の幾何平均を表しています。ハイパー・スレッド処理がtbenchのスループットを22%~31%改善することは明らかです。全体的な改善は5回のテストの幾何平均で27%です。

表6. tbenchのスループットに対するハイパー・スレッド処理の効果
クライアントの数2419s-noht2419s-ht速度の向上
2060.9879.8631%
3059.9477.8230%
6055.8570.1926%
9048.4558.8822%
12037.8547.9227%
幾何平均51.8465.7727%

注意: データは、Mバイト/秒を単位としてのスループット: 大きい値ほど性能が良いことを意味する。

図 3. tbenchのワークロードに対するハイパー・スレッド処理の効果
図3. tbenchのワークロードに対するハイパー・スレッド処理の効果

Linuxカーネル2.5.xでのハイパー・スレッド処理のサポート

Linuxカーネル2.4.xは、リリース2.4.17以降でHTに対応するようになりました。カーネル2.4.17は、論理プロセッサーを認識し、ハイパー・スレッド処理プロセッサーを2個の物理プロセッサーとして扱います。しかし、標準カーネル2.4.xに採用されているスケジューラーは、2個の論理プロセッサーと2個の別個の物理プロセッサーの間の資源の衝突の問題を区別できていないという点で、まだ洗練されていないと考えられています。

Ingo Molnarは、現在のスケジューラーが正しい判断をできない状況を指摘しています (リンク先については参考文献参照)。物理的なCPUを2個装備するシステムがあり、それぞれのCPUでは2個の仮想プロセッサーが使えるものとします。実行中のタスクが2個ある場合、現在のスケジューラーは、一方のプロセスを別の物理的なCPUに移行させたほうが、はるかに高い性能が得られるようになる場合でも、両方のタスクを1個の物理プロセッサーで実行させようとします。また、このスケジューラーは、1個の仮想プロセッサーからその同胞 (同一の物理的CPU上の別の論理CPU) にプロセスを移行させたほうが、物理的プロセッサー間でそれを移行させるよりも (キャッシュ・ロードの関係から) 安価であることを理解していません。

これを解決するには、実行キューの処理方法を変更する必要があります。2.5のスケジューラーは、プロセッサーごとに実行キューを1個ずつ管理し、キューの間でのタスクの移動を回避しようとしています。しかし、変更すべきなのは、物理プロセッサーごとに実行キューを1個ずつ設け、すべての仮想プロセッサーにタスクを振り分けることができるようにするという点です。なぜアイドルCPU (すべての仮想プロセッサーがアイドルになっている) が出てくるのかについてのもっと明晰な判断を導入すれば、ハイパー・スレッド処理システムでのスケジューリングの必要性を「奇麗に満たしてくれる」コードになるはずです。

2.5のスケジューラーの実行キューに変更を加えることの他にも、HTを利用してLinuxカーネルの性能が最適なものとなるようにするための変更も必要です。これらの変更点についてのMolnarの論は、以下のとおりです (詳しくは、参考文献を参照してください)。

  • HT対応の受動的なロード・バランシング:
    IRQ駆動のバランシングは、論理CPUごとにではなく、物理CPUごとに行うべきです。そうしないと、一方の物理CPUがタスクを何も実行していないのに、もう一方の物理CPUが2個のタスクを実行するということが起こり得ます。標準のスケジューラーは、この状態を「不均衡 (imbalance)」と認識していません。スケジューラーからは、最初の2個のCPUが1-1のタスクを実行させ、2つ目の2個のCPUが0-0のタスクを実行させているかのように見えます。標準のスケジューラーは、2個の論理CPUが同じ物理CPUに属していることを理解していません。
  • 「能動的な」ロード・バランシング:
    これは、ある論理CPUがアイドルとなり、物理CPUを不均衡にさせる場合です。これは、もともと標準の1:1スケジューラーには存在しないメカニズムです。アイドルCPUによって招かれる不均衡は、通常のロード・バランサーによって解決することができます。HTの場合、元の物理CPUが実行可能な2個のタスクを実行させている可能性がありますので、これは特別な状況です。実行中のタスクを移行させるのは難しいため、これは、標準のロード・バランサーでは処理することのできない状況です。この移行は不可欠です。そうしないと、一方の物理CPUは2個のタスクを実行させ続け、他方の物理CPUはアイドルのままであり続けるということが起こり得ます。
  • HT対応のタスク選択:
    スケジューラーが新しいタスクを選択する場合、他のCPUからタスクを引き抜いてくる前に、同じ物理CPUを共有するタスクのほうを優先させるべきです。標準のスケジューラーは、その論理CPUにスケジュールされていたタスクだけを選択するようになっています。
  • HT対応の親和性:
    タスクは、論理CPUにではなく、物理CPUに「結合」しようとすべきです。
  • HT対応のウェイクアップ:
    標準のスケジューラーは、「現在の」CPUを認識するだけで、その同胞は認識しません。HTでは、すでにタスクを実行している論理CPU上でスレッドがウェイクアップされ、かつ同胞のCPUがアイドルである場合、同胞のCPUがウェイクアップされ、新たにウェイクアップされたタスクを即座に実行しなければなりません。

本稿執筆時点で、Molnarは、実行キューを共有する (複数のCPUが同じ実行キューを共有できる) という概念を導入することで、標準カーネル2.5.32に対して上のすべての変更内容を実装するパッチを提供しています。物理CPUごとに実行キューを共有することで、上記のHTのスケジューリングに関するニーズをすべて実現しています。当然ながら、これによってスケジューリングやロード・バランシングは複雑なものとなり、SMPや単一プロセッサーのスケジューラーに対する効果は、まだ、わかっていません。

Linuxカーネル2.5.32での変更内容は、XeonシステムでCPUを2個以上使用する場合に、とくにロード・バランシングやスレッド親和性の面での効果を期待して設計されたものです。われわれは、ハードウェア資源の制約から、CPU 1個のテスト環境でしか、その効果を測定することができませんでした。2.4.19で使用したのと同じテスト・プロセスを使用して、2.5.32でchat、dbench、tbenchの3つのワークロードを実行してみました。chatについては、チャット・ルーム数40の場合で、60%もの速度向上を得ることができました。全体的な改善は、約45%でした。dbenchについては、高いほうで27%の速度向上となり、全体的な改善は約12%でした。tbenchについては、全体的な改善が約35%でした。

表 7. Linux カーネル 2.5.32 に対するハイパー・スレッド処理の効果
ワークロードchat
チャット・ルームの数2532s-noht2532s-ht速度の向上
20137,792207,78851%
30138,832195,76541%
40144,454231,50947%
50137,745191,83439%
幾何平均139,678202,03445%
ワークロードdbench
クライアントの数2532s-noht2532s-ht速度の向上
20142.02180.8727%
30129.63141.199%
6084.7686.021%
9067.8970.374%
12057.4470.5923%
幾何平均90.54101.7612%
ワークロードtbench
クライアントの数2532s-noht2532s-ht速度の向上
2060.2882.2336%
3060.1281.7236%
6059.7381.236%
9059.7180.7935%
12059.7379.4533%
幾何平均59.9181.0735%

注意: chatのデータは、クライアントから送信される1秒あたりのメッセージ数。dbenchとtbenchのデータの単位はMバイト/秒。


まとめ

Intel Xeonのハイパー・スレッド処理は、明らかに、Linuxカーネルおよびマルチスレッド型アプリケーションに好ましい効果を与えています。ハイパー・スレッド処理による速度の向上は、標準カーネル2.4.19で30%にもなり、カーネル2.5.32では、スケジューラーでの実行キューのサポートおよびハイパー・スレッド処理への対応といった大きな変更を行ったことから、51%に達しました。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=288668
ArticleTitle=ハイパー・スレッド処理でLinuxを高速化
publish-date=01012003