バージョン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のデータだけが表示されます。

                
   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と表しています。

パイプの待ち時間テストは、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%向上させています。

上に戻る

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には、それに対応する接続数およびスレッド数を示してあります。

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

上に戻る

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%です。

上に戻る

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%です。

上に戻る

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%でした。

上に戻る

まとめ

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

参考文献

• chatベンチマークは、Linuxベンチマーク・スイートのホームページからダウンロードできます。
  
  
• LMbenchについては、LMbenchのホームページに詳しい説明があります。
  
  
• Linuxのエレベーター・アルゴリズム は、Linux Weekly News のKernel Developmentセクション、2000年11月23日号で紹介されています。
  
  
• カーネル・リストにIngo Molnarが寄稿したハイパー・スレッド処理についての2002年8月 の文書は、Linux Weekly Newsに再掲されています。
  
  
• 別の2002年8月 のLWNの記事でも、スケジューラーとハイパー・スレッド処理 (など) が取り上げられています。
  
  
• 筆者は、2002年8月にサンフランシスコで開催されたLinuxWorldコンファレンスでのセッションPerformance tuning for threaded applications -- with a look at Hyper-Threading で貴重な情報を収集できたことについて、IntelのSunil Saxenaにも謝意を表したいと思います。
  
  
• developerWorks のLinuxゾーンには、他にもLinux 開発者向けの参考文献が多数掲載されています。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• Xeonプロセッサーでのハイパー・スレッド処理のサポート
• Linuxカーネル2.4におけるハイパー・スレッド処理のサポート
• カーネル性能の測定
• Linuxカーネルのベンチマーク
• LinuxのAPIに対するハイパー・スレッド処理の効果
• Linuxのシングル・ユーザー・アプリケーション・ワークロードに対するハイパー・スレッド処理の効果
• Linuxのマルチスレッド型アプリケーション・ワークロードに対するハイパー・スレッド処理の効果
• Linuxのマルチスレッド型ファイル・サーバー・ワークロードに対するハイパー・スレッド処理の効果
• tbench
• Linuxカーネル2.5.xでのハイパー・スレッド処理のサポート
• まとめ
• 参考文献
• 著者について
• コメント