配布資料

エンタープライズ向けプロセススケジューラの評価および改良
山村周史
平井聡
久門耕一
株式会社富士通研究所
{yamamura, ahirai, kumon}@flab.fujitsu.co.jp
http://www.labs.fujitsu.com/techinfo/linux/
概要
エンタープライズ分野では過負荷時の安定性や CPU 増加に見合う性能スケーラビリティが重要となる。本論文
では、これらに大きな影響を与えるプロセススケジューラに的を絞り、その改良と性能評価・分析を行った。我々
の改良により、Pentium III Xeon 550MHz を 8 個搭載するサーバ上で、標準カーネルと比較して、Web サーバ性能
が最大 23.3%、チャットルームをシミュレーションするベンチマークプログラムでメッセージスループット性能が
最大 89.6%向上した。また、最新の O(1) スケジューラについて評価を行い、高負荷時において良好な性能を示す
こと、また、その一方で、このスケジューラを実装した場合、ときとして不平等なスケジューリングが行われると
いう問題点について述べる。加えて、Hyper-Threading 対応の最新 CPU における各スケジューラの評価を行った。
その結果、既存スケジューラは、論理 CPU へのプロセス割り当てについて、共有リソース競合への配慮が十分な
されていないことが明らかとなった。本論文ではこれに対応するための簡単な改良についても述べる。
1
はじめに
能を持つ最新 CPU を搭載したシステム上での既存ス
ケジューラの挙動について述べる。最後に 6. で本論文
現在、Linux はデスクトップ用途から Web サーバ、
の総括を行う。
データベースシステムをはじめ幅広く利用されており、
ここ数年は、エンタープライズ分野への拡大が重要な
2
テーマとなっている。これを推し進めるために、大規
模 SMP や NUMA マシンなどをプラットフォームとし
て、高速 I/O、プロセススケジューラ、障害解析、大容
エンタープライズ向けプロセスス
ケジューラの開発動向
Linux をエンタープライズ分野に適用するために、
プロセススケジューラの要件として大きく以下の 2 点
が挙げられる。
量メモリ管理などといったシステム構成要素について
の様々な改良が LSE [1] を中心に続けられている。
中でも、プロセススケジューラは、エンタープライ
ズ用途におけるスケーラビリティの向上をもたらす重
• CPU 数の増加に見合った性能スケーラビリティ
• 過負荷時（多プロセス動作時）における急激な性
能低下の回避
要項目として特に注目が集まっており、短期間に様々
な変更が試みられている。我々は、今後エンタープラ
イズ分野に対して Linux をより一層普及していく上で、
各種スケジューラの性能評価・比較を行い、それらの
現在まで幅広く利用されているカーネル 2.4.x は、
挙動・問題点を把握することが重要であると考えた。
システム上の全実行可能プロセスを単一の runqueue に
そこで、本研究では、カーネル 2.4.x/2.5.x における各
よって管理する。後の節で詳述するように、この実装
種スケジューラの詳細な性能評価および問題点の分析
が上記要件を満たす上で問題となると従来から指摘さ
を行う。
れてきた [2, 3]。
以降、まず 2. においてエンタープライズ分野に Linux
これに対して、様々なスケジューラの改良 [3, 4] が
を適用する上でのプロセススケジューラの要件につい
提案されたが、我々は、独自にメモリバストラフィッ
て述べる。続いて 3. においてカーネル 2.4.x の標準ス
クの観測やカーネルプロファイリングなどを使用した
ケジューラの問題点についてまとめ、それを解決する
分析を行うことで、カーネル 2.4.x の標準スケジュー
ために我々が行った改良手法について詳述する。4. で、
ラ内部においてキャッシュミスが多発するという新た
カーネル 2.5.x において導入された O(1) スケジューラ
な問題点の発見とその解決手法を示した [5]。一方、こ
について詳述するとともに、その性能を評価した結果
れと同時期に、「O(1) スケジューラ」[6, 7, 8] が提案
を報告する。そして、5. において Hyper-Threading 機
された。これもまた、他の改良スケジューラと同様に
1
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
2
カーネル 2.4.x における単一 runqueue による実行可能
ライズ分野においてもその利用が始まりつつある。し
プロセスの管理を回避しようとするものであり、すで
かしながら、SMP マシン上では、高負荷時（多プロセ
に最新（開発）カーネルでの標準スケジューラとなっ
ス動作時）におけるスケジューラの挙動について、こ
ている。
れまで以下のような問題点が指摘されてきた。
しかし、O(1) スケジューラについては他の改良スケ
ジューラと異なり、十分な評価が未だなされておらず、
実際の運用に際しては、性能向上が得られるかどうか
確認するとともにその問題点の洗い出しが必要である。
また、近年、Hyper-Threading 機能を持つ最新 CPU が
登場し、これが今後のエンタープライズ市場において
急速な利用が進むことを考えると、これらスケジュー
ラが、この CPU で構成されたシステムで有効に機能
するか、あるいは、最新 CPU の性能を最大限に引き
出すために問題となることはないかについても調査す
1. 実行可能状態にある全てのタスクを単一のキュー
(runqueue) で管理する。スケジューラは、次に実
行すべきプロセスを選択する際、runqueue を全探
索する。そのため、実行可能状態にあるプロセス
が増加した場合、走査に要する時間が長くなる。
2. SMP システムにおいて、1. の長い走査時間はロッ
ク保持時間の増加とロック競合の増大を招く。こ
れにより、CPU 数が増加した場合の性能向上を妨
げる。
る必要がある。
そこで、我々は、Linux をエンタープライズ分野に
現在まで、LSE (Linux Scalability Effort) を中心とし
展開する上で、以下の 3 点について詳しくまとめるこ
て、上記問題点に関するスケジューラの改善が試みら
とが有用であると考えた。
れており、中でも「Multi Queue スケジューラ」(MQ
スケジューラ) [3] が、SMP システムにおける性能ス
• カーネル 2.4.x の標準スケジューラをメモリアー
キテクチャの観点から調査して明らかとなった問
題点とそれに対する解決手法
• カーネル 2.5.x で採用された O(1) スケジューラが
実際にどれほどの性能向上をもたらすことができ
るかの確認と問題点の調査
• Hyper-Threading 対応 CPU に対してカーネル
2.4.x/2.5.x の標準スケジューラを適用した場合の
システムの挙動
本論文の以降の節において、これらについて詳しく
述べる。
3
カーネル 2.4.x のプロセススケジ
ューラの問題点とその改良
本節では、高負荷な状態でのカーネル 2.4.x の挙動
を、メモリアーキテクチャの観点から分析した結果に
ついて述べる。まず、標準スケジューラ内部で多発す
るキャッシュミスによるスケジューリング性能の低下
について詳述し、これを解決するために我々が行った
改良手法とその評価結果を報告する。
3.1 標準スケジューラの問題点
カーネル 2.4.x は、デスクトップ用途からフロント
エンドマシンなどで広く利用されており、エンタープ
ケーラビリティをもらたすものとして注目されてきた。
MQ スケジューラは、CPU 毎に runqueue を設けて個
別にタスク管理を行うと同時に、runqueue 毎にロック
変数を設ける。これにより、runqueue を短くして走査
時間を短縮するとともに、ロック競合問題を回避して
上記 1, 2 の問題を解決する。
このような問題に対して、我々は、独自に開発した
メモリバス観測ツール GATES [9] を用いて、高負荷時
における Linux システムの挙動をメモリシステムの観
点から評価した。GATES は、共有バス上のメモリト
ランザクションをリアルタイムに観測することができ
る。その結果、次のような新たな問題点を確認した [5]。
カーネル 2.4.x では、システム上の各プロセスの情報を
管理するタスク構造体が、常に物理メモリ上の 8KB 境
界に配置される。そのため、スケジューラが runqueue
を全探策する際、ある特定のキャッシュラインにおい
てアクセス競合が多発する。この場合、runqueue 走査
中にキャッシュミスが頻発し、結果として走査に多大
な時間を消費する。
図 1 は、4-way Pentium Pro 200MHz (2 次キャッシュ
512KB) サーバ上で apache のプロセスを 256 個起動し、
高い負荷をかけているときのメモリバストランザクショ
ンである。横軸はページ内のオフセットアドレス、縦
軸は 1 リクエストあたりのメモリバストランザクショ
ン数である。x86 アーキテクチャでは、物理ページサ
イズは 4KB であるため、そのオフセットアドレスは、
0x0∼0xFFF をとる。図からわかるように、オフセッ
トアドレス 0x30 におけるメモリバストランザクショ
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
peak (0x030)
task #0
task #1
task #2
state
state
state
lock_depth
lock_depth
lock_depth
counter
counter
counter
nice
nice
nice
policy
policy
policy
400
32 bytes
350
300
250
200
150
32 bytes
100
50
0
000
200
400
600
800
A00
C00
E00
offset address
runqueue_head
# of transactions per request
450
3
*mm
*mm
*mm
has_cpu
has_cpu
has_cpu
processor
processor
processor
cpus_allowed
cpus_allowed
cpus_allowed
run_list.next
run_list.next
run_list.next
run_list.prev
run_list.prev
run_list.prev
図 1: メモリバストランザクションの測定結果
図 2: タスク構造体と runqueue の構造
ン数が突出している。これは、当該アドレスへのアク
セスに対してキャッシュミスが多発した結果である。
図 2 にカーネル 2.4.x1 におけるタスク構造体と run-
queue の構造を示す。スケジューラは、次に実行すべき
プロセスを選択するために goodness 計算を行う [10]。
このときに参照する変数は、8KB 境界に配置されてい
るタスク構造体の先頭から 0x20∼0x3F (32 バイト)
の位置に格納されている。従って、当該 32 バイトの物
理メモリアドレスは 8KB(213 ) ∗ n + (0x20∼0x3F) とな
り、下位 13 ビットが常に同一の値となる。x86 アーキ
テクチャでは、キャッシュラインとメモリアドレスと
のマッピングを下位ビットを用いて決定するため、ス
ケジューラがポインタをたどってタスク構造体に連続
してアクセスすると、同一キャッシュライン上で競合
する可能性が非常に高くなる。結果、runqueue 走査中
にキャッシュメモリが有効に機能せず、図 1 のように
特定のメモリアドレスに対して多数のバストランザク
ションが発生する。
特に、SMP カーネルにおいては、runqueue はロック
で保護されている。そのため、キャッシュミスの発生に
より探索時間が長くなると、それと比例してロック保
持時間も長くなる。結果として、CPU 数が増加した場
合にロック競合の割合が高くなり、スケーラビリティ
が得られないという問題が発生していた。これによる
性能低下については、次節以降で詳しく述べる。
3.2 キャッシュライン競合の削減によるスケ
ジューラの高速化
3.1 で述べたような、メインメモリ上での配置によっ
て生じるキャッシュコンフリクトの集中という問題を
解決する手法として、「カラーリング」がよく知られ
1 厳密には、図
2 はカーネル 2.4.4 におけるタスク構造体である。
ている [11, 12]。従って、カラーリングをタスク構造
体に対して適用することで問題を解決できると考えら
れる。
しかしながら、現在まで、Linux カーネルにおいてタ
スク構造体をカラーリングすることはできないと考えら
れていた。これは、カーネルがカレントプロセスの情報
(例えば pid など) を得るときに使用する CURRENT マ
クロ [10] が、
「タスク構造体が物理メモリ上で 8KB(213 )
境界に配置されていること」を想定して記述されてい
るからである。従って、タスク構造体のメモリ上での
位置をずらしてカラーリングを行うと、カーネルが正
常に動作しなくなる。そのため、単純にカラーリング
をタスク構造体に対して適用することは困難であり、
現在まで行われていなかった。
これに対し我々は get_current() にごくわずか
な修整を施すことでカラーリングを実現できることに
気づいた。図 3 は、修整した get_current() であ
る。図からわかるように、太字で示した 1 行のみの修
整である。この関数は、キャッシュラインサイズの倍
数だけ「ずれた」ベースアドレスを呼び出し元に返す。
get_current() は、システム内部で頻繁に呼び出さ
れる。従って、数回のビット操作命令を追加するだけ
に留め、オーバヘッドを抑えている2 。以上のようなわ
ずかな修整でスケジューラ内部で発生していたキャッ
シュライン競合の問題を解決することが可能となる。
2 実際にカーネルを正常に動作させるためには、これ以外のソー
スファイルに対しても若干の修正が必要となる。しかし、変更は非
常に少なく patch ファイルにして 200 行程度である。
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
4
static inline struct task_struct * get_current(void)
{
struct task_struct *current;
__asm__("andl %%esp,%0; ":"=r" (current) : "0" (~8191UL));
(unsigned long)current |= ((unsigned long)current >> 10) & 0x00000060;
return current;
}
この1行を追加
図 3: 修正した get_current()
プロセッサ
2 次キャッシュサイズ
メインメモリ
ネットワークカード
ディストリビューション
Pentium III Xeon 550 MHz × 8
1 MB (4-way set associative)
1 GB
Netgear GA622T (1 GbE) × 4
RedHat 7.1 (US)
【Chat micro benchmark】
Chat ベンチマーク [3, 14] は、上記の WebBench と
は異なり、クライアントマシンを必要としない。この
ベンチマークは、TCP ソケット通信を行う複数のユー
ザがいるチャットルームをシミュレーションする。各
表 1: サーバの構成
チャットルームには、20 人のユーザがおり、各ユーザ
は 100 バイトを単位としてメッセージの送受信を行う。
3.3 性能評価
サーバ側およびクライアント側にそれぞれ、メッセー
ジを送受信する 2 つのスレッドを起動するので、1 ユー
3.3.1
評価環境
評価用サーバとして、富士通製 GRANPOWER 5000
(HS 900) を使用した。サーバ構成を表 1 に示す。ま
た、ベースとなるカーネルのバージョンは 2.4.4 を使
用した。
本論文での評価の目的である高負荷時におけるスケ
ジューラの性能について調査するために、ベンチマー
クプログラムとして以下の 2 つを選択した。
• WebBench 3.0
ザあたり計 4 スレッド生成される。従って、1 チャッ
トルームあたり 80 個のスレッドが生成されることと
なる。
Chat ベンチマークは、チャットルームの数および各
ユーザが送受信するメッセージの個数をパラメータと
して渡すことができる。本論文の評価では、30 チャッ
トルーム、1 ユーザあたり 300 メッセージに設定した。
この場合、2400 プロセス (スレッド) がシステム上に
生成される。
いずれのベンチマークアプリケーションも、サーバ上
で多数のサーバプロセスが起動し、クライアントから
の多数のリクエストを処理する。そのため、スケジュー
ラの性能について集中的に評価を行うことができる。
【WebBench 3.0】
WebBench 3.0 [13] は、Web サーバ性能の評価を行
うベンチマークアプリケーションであり、1 秒あたり
に処理したリクエスト数を性能の指標とする。
本実験では、サーバプログラムとして Apache 1.3.19
を用いた。実験中、サーバ上で 256 個のサーバプロセ
ス (httpd) を起動する。
サーバに対してリクエストを送信するクライアント
マシンとして、28 台の PC/AT を用意した。各クライ
アントマシンは、OS として Windows NT Workstation
4.0 (SP5) を使用した。WebBench を実行する場合、28
台の PC/AT 上で 256 個のクライアントスレッドを起動
し、リクエストを同時に発行する。
• Chat micro benchmark
図 4: WebBench 性能
3.3.2
結果
各ベンチマークの測定結果を図 4、5 に示す。これら
の図からわかるように、改良カーネルは、WebBench
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
5
図 5: Chat 性能
図 6: ロック競合およびキャッシュミス率 (8CPU の場合)
および Chat ともに標準カーネルに比べ大きくスケー
短縮される。同時に、ロック競合率も、WebBench で
ラビリティが改善されている。
45.6%から 23.4%、Chat で 85.8%から 69.7%と大きく
減少している。
WebBench では、1 秒あたりに処理したリクエスト
数が 8CPU の場合で最大 23.3%増加している。また、
本節での評価の結果、本改良手法を用いることで標
Chat については、6CPU の場合、標準カーネルに対し
て 89.6%もの性能向上が得られている。標準カーネル
は 4CPU まで若干性能が向上し、それより CPU 数が
多い場合には性能が劣化しているのに対して、カラー
リングしたカーネルでは、6CPU まで性能が大きく向
上している。
が異なり、それらと互いに直交するものである。従っ
カラーリングによる本改良手法は、(1) runqueue 走
て、本改良手法を他スケジューラと組み合わせること
準スケジューラの問題点を解決し、CPU 数の増加に対
する性能スケーラビリティを大きく向上できることが
わかった。我々の取り組んだスケジューラ内部におけ
るキャッシュミス多発の問題は、すでに提案されてい
る MQ スケジューラなどの他のスケジューラと着眼点
査時のキャッシュミスを減少し、その走査時間を短縮、
(2) ロック競合を低減、の 2 つの相乗効果によってシ
ステム全体の性能向上をねらう。実際に、この効果が
得られているか確かめるために、8CPU の場合につい
て、以下の 2 項目の計測を行った。
も可能である。
L2 キャッシュミス率 runqueue を走査する
list_for_each ループ内での L2 キャッシュミ
ス回数および L2 キャッシュへのアクセス回数を
測定した。測定には CPU に装備された性能モニ
タリングカウンタを用いた。L2 キャッシュミス率
は、(L2 キャッシュミス回数)/(L2 キャッシュア
クセス回数) で計算する。
4
なお、本改良に関する基本的な内容は、USENIX Annual Technical Conference 2002 にて発表を行った。さら
に詳細なデータについては、文献 [5] を参照されたい。
カーネル 2.5.x のプロセススケジ
ューラの性能評価
前節において、エンタープライズ分野にカーネル
2.4.x を適用する上でのプロセススケジューラの問題
点を明らかにし、それを解決するためのカーネルの改
良手法を示した。
ロック競合率 runqueue を保護するロック変数 (run-
一方、現在の最新（開発）カーネルであるバージョ
queue_lock) について、Lockmeter [15] を使用
してロックの競合発生率を測定する。
して、「O(1) スケジューラ」が導入されている。O(1)
ン 2.5.x においては、標準的なプロセススケジューラと
スケジューラは、2002 年初頭に Ingo Molnar が Linux
結果を図 6 に示す。この結果から分かるように、標
カーネルメーリングリストに投稿したものであり、カー
準カーネルでは、85%∼90%以上と L2 ミス率としては
ネル 2.4.x における標準スケジューラの問題点を一挙
異常な値を示していたものが、改良カーネルでは大幅
に解決しようとするものである。本節では、O(1) スケ
に改善されている。これにより、runqueue 探策時間が
ジューラを実装したシステムの評価を行い、その性能
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
を確認する。そして、これまで指摘されていなかった
O(1) スケジューラの不平等スケジューリングの問題に
ついて述べ、これについて実験および考察を行う。
6
runqueue
次にCPUで実行
するプロセス
active
bitmap
4.1
O(1) スケジューラの特徴
大
優先度
O(1) スケジューラの概念図を図 7 に示す。O(1) スケ
(b) runqueue_lock の分散上記 (a) の 2 配列が各 CPU 毎に用意されており、
それぞれ独立したロック変数によって保護されて
いる。
(c) CPU 間でのプロセス移動各 CPU 間で分散された runqueue の間で、適切に負
荷バランスを保つための関数 load_balance()
が実装されている。また、この関数は、キャッシュ
メモリの利用効率を考慮し、CPU 間のプロセス移
動を抑えるように作用する。
O(1) スケジューラでは、図 7 に示すように、2 つの
優先度付き待ち行列で runqueue を構成している。それ
ぞれ “active”, “expired” と呼ばれ、active は、実行中の
プロセスを管理し、他方 expired は、クォンタム（割
クォンタムを使い切った
プロセスは移動
expired
負荷バランス
関数 load_balance()
ジューラは、主として以下のような特徴を有している。
(a) 優先度付き待ち行列による実行可能プロセス管理
実行可能プロセスは、配列構造とリスト構造とを
組み合わせて実装された優先度付き待ち行列で管
理される。各配列要素は、同一優先度からなるプ
ロセスのリストである。
小
ロック
CPU
CPU
CPU
図 7: O(1) スケジューラ概念図
スを保つように他の CPU の runqueue からプロセスを
奪う処理を行う。
加えて、O(1) スケジューラではキャッシュに転送さ
れたデータの有効利用を図るために、できる限り CPU
間でのプロセスの移動を抑えるようにしている。これ
により、キャッシュのヒット率が向上しプロセスの実
行時間が短縮されることが期待できる。
以上のような工夫により、O(1) スケジューラは、3.1
で述べた 2.4.x 標準スケジューラの問題であった単一
runqueue の線形探策とロック競合の問題の解決を図っ
ている。これにより、SMP マシンにおけるスケーラビ
リティ向上をねらう。
り当てられた CPU 持ち時間）を使い切ったプロセス
を保持している。クォンタムを使い切ったプロセスは、
4.2 性能評価
active から expired に移動される。active が空になった
4.2.1 実験環境
場合は、これらの配列をスワップする。各配列には、
プロセスキューの有無を示すビットマップが用意され
O(1) スケジューラの効果を確認するために、3. で
ており、これを参照することで、最も高い優先度を有
使用した実験環境およびベンチマークプログラム
するプロセスリストの位置（active 配列内のインデッ（WebBench, Chat）を使用して性能評価を行った。た
クス）を高速に決定することができる。これによって、
だし、本節の評価では、評価に用いるカーネルのバー
標準スケジューラのようにプロセスリストを線形探索
ジョンを 2.4.18 とし、以下の 3 つのカーネルの性能を
することなく、次に CPU に割り当てるべきプロセス
測定した。
を直接参照することができる3 。
1. 標準カーネル
また、各 CPU 間で負荷バランスを取るために、
2. 標準カーネル + O(1) スケジューラパッチ
load_balance() が用意されている。この関数は、
3. 標準カーネル + Multi Queue スケジューラパッチ
自身がアイドル状態にある場合やタイマ割り込みを契
機として一定間隔で呼び出され、CPU 間の負荷バラン
サーバの CPU 数を 1 台から 8 台まで変化させ、こ
3 「計算に要するオーダが
1 である」という名前の由来
れら 3 つのカーネルの性能を測定した。
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
7
表 2: WebBench の性能およびスピンロック関数の実行比率
スケジューラ
標準スケジューラ
O(1) スケジューラ
Multi Queue スケジューラ
標準スケジューラ
O(1) スケジューラ
Multi Queue スケジューラ
性能 [リクエスト/秒]
スピンロック
1 CPU
1,332 (1.00)
1,401 (1.05)
1,319 (0.99)
–
–
–
2 CPU
2,038 (1.53)
2,314 (1.74)
2,192 (1.65)
1.62 %
0.00 %
0.07 %
4 CPU
3,613 (2.71)
4,210 (3.16)
4,054 (3.04)
6.14 %
0.00 %
0.04 %
8 CPU
5,074 (3.81)
6,042 (4.54)
6,019 (4.52)
18.81 %
0.00 %
0.03 %
表 3: Chat の性能およびスピンロック関数の実行比率
スケジューラ
標準スケジューラ
O(1) スケジューラ
Multi Queue スケジューラ
標準スケジューラ
O(1) スケジューラ
Multi Queue スケジューラ
性能 [×103 メッセージ/秒]
スピンロック
1 CPU
126 (1.00)
119 (0.94)
121 (0.97)
–
–
–
8 CPU
183 (1.45)
392 (3.11)
362 (2.88)
31.25 %
0.06 %
1.56 %
図 8: O(1) スケジューラの WebBench 性能測定結果
4.2.2
4 CPU
201 (1.60)
282 (2.25)
269 (2.14)
15.02 %
0.03 %
1.65 %
2 CPU
136 (1.08)
144 (1.15)
145 (1.15)
5.51 %
0.03 %
1.25 %
結果
図 9: O(1) スケジューラの Chat 性能測定結果
るように、CPU 数が増加するにしたがって O(1) スケ
ジューラによる性能向上比は大きくなっている。スピ
WebBench の測定結果を図 8、および表 2 に示す。
ンロック処理時間の割合も、標準スケジューラにおい
また、Chat の測定結果を図 9、および表 3 に示す。表
て 8 CPU 時 18.81%であったものが O(1) スケジュー
には、高負荷時におけるスケジューラの性能を大きく
ラではほぼ 0%にまで抑えられている。しかし、Multi
左右するスケジューラ内部におけるスピンロック関数
(_text_lock_sched()) について、その処理時間が
実行時間全体に占める割合もあわせて示した。なお、
表中カッコ内の数値は、1 CPU 構成のサーバ・標準ス
ケジューラ上での性能を 1 とした場合の性能比である。
Queue (MQ) スケジューラと比較すると、ほとんど性
能差がみられない。WebBench では、MQ スケジュー
ラを用いた場合でも十分にロック競合が減少しており、
これら 2 つのスケジューラは同等の性能を示している。
WebBench については、グラフからわかるように、
O(1) スケジューラは標準スケジューラに比べ性能が改
善されている。1 秒あたりに処理したリクエスト数は、
8 CPU の場合で最大 19.0%増加している。表からわか
Chat については、グラフから分かるように、O(1) ス
ケジューラは標準スケジューラと比較してスケーラビ
リティが大幅に向上している。標準カーネルでは、5
CPU 以降性能が劣化するのに対して、O(1) スケジュー
ラでは 8 CPU まで性能が向上している。このとき、標
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
!"
#
$%
!"
#$%
&'
"
%&'
8
'()
(a) 標準スケジューラ
(b) O(1) スケジューラ
図 10: WebBench 実行時の OS 関数プロファイル
準カーネルに対して 114%の性能向上が得られている。
は、ネットワークパケット処理 ( network_driver
runqueue に並ぶプロセスの数が、WebBench の場合で
最大 256 程度であるのに対して、Chat の場合は 1000 プ
ロセス以上とはるかに多い。MQ スケジューラの場合、
CPU 毎にロック変数の分割は行っているが、runqueue
内を線形探策することについては標準スケジューラと
同じである。そのため、O(1) スケジューラの特徴であ
る高速なプロセス探策とロック競合の低減とがより有
効に機能し、Chat のように非常に多くのプロセスが生
成される場合には最も良い結果を示している。
および csum_partial_copy_generic) となってい
る。またロック変数についても、スケジューリングに
おける競合よりも、dcache_lock（ディレクトリエント
リキャッシュ）における競合が問題となっており、スケ
ジューリングにおける問題は解決できていると言える。
4.3
O(1) スケジューラの問題点
前節までで、多数個のプロセスが生成される場合に
ついて、O(1) スケジューラの性能評価・考察を行い、
4.2.3
カーネルプロファイリングによる分析
O(1) スケジューラの効果をさらに詳しく調査するた
めに、WebBench 実行中のカーネルプロファイリング
を採取し分析を行った。
このスケジューラが他と比較して高い性能を示すこと
を確認した。しかし、その一方で、我々は様々な状況
での実験を重ねていく過程で、O(1) スケジューラに問
題点があることに気づいた。
O(1) スケジューラを利用した場合、SMP マシン上
では不平等なプロセスのスケジューリングが行われる
時間の多い上位 5 関数、その他の OS 処理部分、およ
ことがある。このような現象は、標準スケジューラで
びユーザプログラム実行時間に分割して表示している。
は見られない。本節では、この問題について簡単な実
ただし、“network_driver” は、ネットワークドラ
験を行った結果について報告する。
イバ内部での処理時間を示しており厳密には 1 関数で
【実験方法】
はない点に注意されたい。
実験では、前節までの評価に用いた環境（8-way Pen図 10 (a) 標準カーネルでは CPU 数が 1∼4 CPU の
tium III サーバ、2.4.18 カーネル）と同じものを使用し
場合は、schedule() 関数の占める割合が最も大き
た。実験を簡単にするため、これを 4 CPU 構成で起動
い。これは、標準スケジューラが長い runqueue を線
し、100 × 106 回の空ループを実行するプロセスを 5 つ
形探策するために多くの時間を消費しているためであ
同時に起動する。各プロセスの実行時間とともに、実
る。8 CPU の場合は、_text_lock_sched() 関数
行中に各プロセスがどの CPU 上で実行されているか
の占める割合が急激に増加している。これは、単一の
（カレント CPU）を一定間隔でサンプリング測定する。
runqueue_lock における競合によるものである。
【結果・考察】
一方、図 10 (b) O(1) スケジューラでは、標準スケ
結果を表 4 に示す。この表は、実行に要した実時間、
ジューラで問題となっていた上記関数は上位には現れ
および各プロセスがどの CPU 上で実行時間の何%を消
費したかを示したものである。また、O(1) スケジュー
ない。WebBench による評価では、性能ボトルネック
結果を図 10 に示す。グラフには、OS 内部での処理
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
9
表 4: O(1) スケジューラによる不平等なプロセススケジューリング（経過時間と CPU 使用率）
標準スケジューラ
O(1) スケジューラ
プロセス
経過時間 [秒]
0
1
2
3
4
プロセス
0
1
2
3
4
5.89
5.45
5.93
5.62
5.17
経過時間 [秒]
6.89
6.80
4.55
4.55
4.55
CPU0 [%]
24.5
12.2
22.5
25.3
27.0
CPU0 [%]
49.0
0.0
0.0
0.0
100.0
CPU1 [%]
28.6
4.1
16.3
52.2
25.2
CPU1 [%]
0.0
0.0
0.0
100.0
0.0
CPU2 [%]
28.6
24.5
28.6
0.0
25.4
CPU2 [%]
0.0
0.0
100.0
0.0
0.0
CPU3 [%]
18.4
59.2
32.7
22.4
22.4
CPU3 [%]
51.0
100.0
0.0
0.0
0.0
らず、より多くのプロセスが生成される場合でもこの
問題は発生する。
このような不平等なスケジューリングについては、
例えば、ターンアラウンドタイムが重要視されるよう
なシステムで O(1) スケジューラを使用する場合に注
意が必要であるし、また、複数のプロセスが同期を取
りながら並列動作する場合には最長実行時間のプロセ
スによって並列プログラムの実効性能が律速されてし
まうことも考えられる。実際には、4.1 で述べたよう
に、キャッシュメモリの利用効率を考慮して CPU 間
のプロセス移動を抑える、という O(1) スケジューラ
の実装が大きく影響していると考えられるので、こ
図 11: O(1) スケジューラによる各プロセスのスケジュー
れを解決するために、CPU 間でのプロセス移動を行
リング
う load_balance() の改善が今後必要であると言
える。
ラについて、横軸を経過時間、縦軸を CPUID として
各プロセスのカレント CPU をプロットしたものを図
プロセススケジューラの最新 CPU
への適用とその問題点
5
11 に示す。
表 4 からわかるように、標準スケジューラに比べ、
O(1) スケジューラは各プロセスのスケジューリングに
大きな偏りが見られる。標準スケジューラでは各プロ
セスがほぼ均等に複数の CPU 上で動作しているのに対
し、O(1) スケジューラではある特定の CPU でプロセス
が動作し続ける。5 プロセスの実行時間について、平均
値に対する分散の比率を計算すると、標準スケジュー
ラが 3.8%、O(1) スケジューラが 30.5%となり、実行時
間に大きなばらつきがある。図 11 からわかるように、
プロセス 2, 3, 4 はそれぞれ 1 台づつ CPU を占有して
いるのに対して、プロセス 0, 1 は 1 台の CPU を交互
に使用していることがわかる。このような不平等なス
ケジューリングが行われるために、各プロセスの実行
時間に大きな差が生じる。本論文では詳しく述べない
が、このような少数のプロセスが起動される場合に限
3.、4. において、カーネル 2.4.x/2.5.x におけるプロセ
ススケジューラの性能評価・比較を行った。本節では、こ
れらのプロセススケジューラを、近年登場した Hyper-
Threading 機能を持つ Intel Xeon プロセッサ [16, 17]（以
下 Xeon と略記）に対して適用する場合について調査
を行う。Hyper-Threading 機能を利用した場合、実際に
システム性能の向上が得られるかを確認するとともに、
既存のプロセススケジューラが Hyper-Threading 機能
を有効に利用できていない点について明らかにする。
そして、この問題を解決するために我々が行った改良
について詳述し、簡単な実験を行った結果について述
べる
以下、評価にあたって、まず、Hyper-Threading 機能
の概要を説明し、既存のプロセススケジューラを適用
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
する上で懸念される点について述べる。
10
は、物理 CPU 内部で共有されている演算リソースの
競合を考慮したスケジューリングが必要となる。具体
5.1
的には、ある物理 CPU 上で 2 つのプロセスが同時に
Hyper-Threading 機能の概要
走行している場合、各プロセスは実質的に半分の計算
Hyper-Threading 機能とは、一般に SMT (Simultaneous Multithreading) [18, 19] と呼ばれる CPU アーキテ
クチャの 1 実装である。このアーキテクチャは、複数
の命令流（スレッド）を 1 つの物理 CPU 内部で同時に
実行することで、CPU 内部の演算器（ALU や浮動小
数点演算器など）の稼働率を上げ、CPU のスループッ
ト性能を向上しようとするものである。
資源しか使用できず、1 プロセスのみで走行する場合
に比べて性能が大きく低下してしまう。従って、Xeon
で構成された SMP システムにおいては、プロセスを
スケジューリングする場合には、「可能な限り 1 つの
物理プロセッサにつき 1 プロセスが走行するようにス
ケジューリングを行う」ことが重要となる。
しかしながら、Linux カーネルはこの CPU を 2 CPU
が搭載された SMP システムと認識し4 、従来の SMP
カーネルにおけるスケジューリングポリシーを単純に
物理CPU
論理CPU 0
適用する。従って、例えば、システム上で少数のプロ
論理CPU 1
セスを起動した場合に、それらが同一物理 CPU に対
アーキテクチャ
ステート
アーキテクチャ
ステート
して割り当てられる場合がある。そのため、同一のプ
ログラムを実行しているにもかかわらず、スケジュー
共有リソース
リングによって実行時間に大きなばらつきが出る可能
性がある。以降の節では、この CPU を複数個搭載し
・実行ユニット
・Trace Cache
・2次キャッシュメモリ
etc
たサーバを使用して、Hyper-Threading 機能による性能
向上を確認するとともに、上記問題点について検討を
行う。
図 12: Hyper-Threading 機能を搭載した CPU の概念図
5.2
5.2.1
表 5: 各種計算資源の共有/独立
共有リソース
レジスタ (EIP, etc)
実行ユニット
命令 TLB
データ TLB
実行トレースキャッシュ
1 次データキャッシュ
2 次キャッシュ
独立リソース
⃝
⃝
⃝
⃝
⃝
⃝
⃝
Xeon では、図 12 のように 1 つの物理 CPU 内部に 2
Hyper-Threading 機能の評価
評価環境
Xeon を 2 台搭載したサーバ上で既存スケジューラの
性能について、4. までの評価と同じく WebBench を用
いて評価を行った。サーバ構成を表 6 に示す。カーネ
ルのバージョンは 2.4.18 を基本とし、標準スケジュー
ラおよび O(1) スケジューラの 2 種類について評価を行
う5 。サーバ上で Web サーバプロセス (httpd) を 256 個
起動し、28 台の PC/AT 上で起動されたクライアント
スレッドからのリクエストを処理する。実験では、ク
ラインアントスレッドの数を 1∼256 に変化させ、サー
バのリクエスト処理性能を測定する。
つの論理 CPU が存在している。論理 CPU は、独立し
たアーキテクチャステートと論理 CPU 間で共有された
演算リソースから成っている。アーキテクチャステー
トとは、単一スレッドを実行するために保持しておく
5.2.2
結果
測定結果を図 13 に示す。図中 P x(on/off) は、稼
必要がある CPU の実行環境（各種レジスタの値など）
働している物理プロセッサが x 個であり、カッコ内に
であり、一方、共有リソースとしては、実行ユニット
おいて Hyper-Threading 機能の on または off を示して
や 2 次キャッシュメモリ、実行トレースキャッシュなど
がある。表 5 に各演算リソースの論理 CPU 間での共
有/独立をまとめた。
この CPU の本来のシステム性能を引き出すために
4 厳密には、最新のカーネルは CPU の cpuid をチェックして物理
あるいは論理 CPU を区別している
5 Xeon を複数搭載したサーバでカーネル 2.4.18 を使用した場合、
ある CPU に割り込みが集中するという問題がある。実験に使用し
たカーネルではこれを修正するパッチを別途適用している
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
11
(a) 標準スケジューラ
(b) O(1) スケジューラ
図 13: WebBench 性能
この種のアプリケーションの場合、リソース競合の
表 6: 実験に用いたサーバの構成
問題について特に考慮せずとも既存スケジューラを適
用することで Hyper-Threading 機能を活用できている
プロセッサ
2 次キャッシュサイズ
メインメモリ
ネットワークカード
ディストリビューション
カーネルバージョン
Intel Xeon 2.00 GHz × 2
512 KB
512 MB
Intel EtherExpress Pro/100 × 2
Netgear GA622T (1GbE) × 2
RedHat 7.2 （US 版）
2.4.18
2.4.18 + O(1) パッチ
と言える。
表 7: Hyper-Threading 機能によるピーク性能の向上
（カッコ内は off の場合に対する性能比）
物理 CPU 数
1CPU
2CPU
いる。また、表 7 にピーク性能をまとめたものを示す。
スケジューラ
標準
O(1)
標準
O(1)
Hyper-Threading
off
on
2220 3159 (1.42)
2818 3711 (1.32)
4284 5104 (1.19)
5201 6127 (1.18)
結果からわかるように、標準スケジューラ、O(1) スケ
ジューラともに Hyper-Threading 機能を on にした場合
に性能が向上している。ピーク性能の向上比は、1CPU
の場合 30∼40%、2CPU の場合 18∼19%程度である。
5.3
標準スケジューラの場合、P2 (off) のときにクライア
Hyper-Threading 機能を活用するため
のスケジューラ改良
ント数が 192 以上で性能が劣化している。これは、負
荷が 100%になってリクエストが処理しきれず、httpd
プロセスが runqueue に並び始めたためである。このよ
5.3.1
既存スケジューラの問題点とその改良
5.2 で述べたように、多プロセス動作時においては、
うに、標準スケジューラについては SMP の場合と同
従来のスケジューラを用いても大きな問題は発生し
様の問題は発生しているものの、いずれのスケジュー
ていなかった。しかし、5.1 で述べたように、Hyper-
ラについても Hyper-Threading 機能を使用することで
Threading 機能を持つ CPU で構成された SMP マシン
性能が向上している。
においては、プロセスをスケジューリングする際に「可
スケジューラの観点からすると、WebBench は以下
のような特徴を有している。
能な限り 1 つの物理プロセッサにつき 1 プロセスが走
行するようにスケジューリングを行う」ことが重要と
• CPU の個数を越える多数個のプロセスが常に実行
可能状態にある（runqueue に並んでいる）。
なる。しかしながら、いずれの既存スケジューラも上
• 複数のサーバプロセス（httpd）が各々独立してリ
クエストを処理しており、互いに同期を取るよう
なことはほとんどない。
について、まずこの問題点の検討および改良を行う。
記の点を十分に考慮できていない。本節では、安定版
カーネルとして特に改良が急がれる標準スケジューラ
標準スケジューラにおいて、具体的に以下の 2 点が
問題となる。
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
(1) schedule() 関数における優先度計算あるプロセスの優先度 (goodness) を計算する場合、
スケジューリングを行う CPU と当該プロセスが
以前走行していた CPU とが同じである場合、一
定の優先権を与える。そのため、2 つのプロセス
が同一物理 CPU 内部の 2 つの論理 CPU で走行し
続けてしまうことがある。
(2) reschedule_idle() 関数における CPU の選択
reschedule_idle() 関数は、プロセスの起床時に呼
び出される。このとき、当該プロセスの以前走行
していた CPU が idle 状態である場合には、その
CPU に対して当該プロセスを割り当てる。その
ため、図 14 のように、一方の物理 CPU が idle 状
態にあるにもかかわらず割り当てられない場合が
ある。
物理CPU 0
5.3.2
12
実験
前節での改良を確かめるために簡単な実験を行った。
【実験方法】
実験では、実行時間の異なるプロセスを 2 つずつ起
動し、全プロセスが実行を完了するまでの時間を測定
する。各プロセスは、100 × 106 回、500 × 106 回の単
純ループを実行する。ループ内部では、事前に確保さ
れた 4KB のメモリ領域をサイクリックに read するだ
けである。これを 10 回繰り返す。各プロセスの実行
時間を測定すると同時に、実行中に各プロセスがどの
CPU 上で実行されていたか（カレント CPU）を一定
間隔でサンプリング測定する。
【結果・考察】
結果を表 8 に示す。また、図 15 に横軸を経過時間、
縦軸を論理 CPU ID として、各プロセス実行中のカレ
ント CPU の測定結果をプロットしたものを示す。
物理CPU 1
論理CPU 0
論理CPU 1
論理CPU 2
論理CPU 3
プロセス0
実行中
アイドル
状態
アイドル
状態
アイドル
状態
表 8: 4 つのプロセスが全て終了するまでの時間
標準スケジューラ
改良スケジューラ
別スレッドが走行する
物理CPUに割り当て
プロセス1が
新たに生成
最短 [秒]
12.6
12.6
最長 [秒]
19.8
12.7
平均 [秒]
15.5
12.6
アイドル状態の
物理CPUに割り当て
これらからわかるように、標準スケジューラでは、
図 14: reschedule_idle() 関数における誤ったプロセス
最短時間と最長時間との差が非常に大きい。これは、
スケジューリング
図 15 (a) のように実行時間の長いプロセスが同一物理
CPU 内部で動作し続けてしまうためである。一方、最
短の時間で終了する場合は、実行時間の長いプロセス
が異なる物理 CPU で動作した場合である。標準スケ
ジューラの場合、これらいずれかの状況がランダムに
発生するために、動作が安定しない。
一方の改良スケジューラでは、図 15 (b) のように、
一方の物理 CPU が idle 状態になったときにプロセス
の移動が行われている。これにより、常に最良の状態
で 4 つのプロセスの実行が行われる。最長の実行時間
について、その性能差は 1.5 倍以上になる。
この実験は、単純なループ処理を行うプログラムを
用いた一例であるが、実際の並列アプリケーションや、
実稼働するサーバマシンへのバッチジョブの投入など
においてもこのような状況が発生することは十分に考
えられる。また、互いに同期をとりながら動作する並
列プログラムなどの場合、標準スケジューラでは最も
実行時間の長いプロセスでプログラム全体の実行時間
が抑えられてしまうことも考えられる。この場合、今
回の改良が有効であると予想できる。
本節では、特にカーネル 2.4.x の標準スケジューラ
について言及したが、カーネル 2.5.x における O(1) ス
そこで、我々は、この問題点を解決するために標準
スケジューラの改良を行った。実際には、schedule() 関
数内部と reschedule_idle() 関数にそれぞれ以下のよう
な修整を加えた。
(1) schedule() 関数に対する修整関数内部において、全プロセスの優先度計算終了
後、以下の条件をチェックする。
• runqueue に並んだプロセスがすべてクォン
タムを使い切った。
• idle 状態にある物理 CPU が存在する。
この場合、idle している物理 CPU にカレントプロ
セスを移動する。
(2) reschedule_idle() 関数に対する修整 idle 状態にある物理 CPU が存在するかどうかを他
の条件に優先してチェックする。存在すれば、
（当
該プロセスが以前走行していた CPU と異なって
いても）その CPU に当該プロセスを割り当てる。
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
13
(a) 標準スケジューラ（実行時間 19.8 秒）
(b) 改良スケジューラ（実行時間 12.6 秒）
図 15: 各プロセスが走行していた CPU
ケジューラでも同様の問題が起こり得る。これに対し
た計算能力をプロセスが実際に使用したかどうか保証
ても、例えば load_balance() などのスケジューリ
できない。
ングに関連する部分に本節で述べたスケジューリング
今後は、このような問題を考慮し、CPU 内部の計算
ポリシーを適用することで同様の効果が期待できる。
資源が割り当てられたかどうかを表す新たな指標が必
要になると考えられる。
5.4
Hyper-Threading 対応 CPU における時
分割制御に関する考察
これまでで述べたように、Hyper-Threading 機能を
6
おわりに
本論文では、エンタープライズ用途という観点から、
搭載した CPU では、あるスレッド（プロセス）の実
カーネル 2.4.x の標準スケジューラの問題点についてま
行が同一物理 CPU 内部で動作している別のスレッド
とめ、これを解決するために、標準カーネルのタスク構
の影響を受ける。そのため、同一のプログラムを実行
造体に対してキャッシュカラーリングを適用した。これ
しても、単独で動作している場合に比べて、見かけ上
により、8-way Pentium III Xeon サーバにおいて、Web
CPU 性能が低下してしまう恐れがある。同時に、当該
プロセスのユーザ時間（CPU 利用時間）は延びる結果
となる。
サーバ性能が 23.3%、Chat ベンチマークで 89.6%の性
能向上を達成した。また、カーネル 2.5.x で新たに導
入された O(1) スケジューラについて詳細な性能評価
従来のオペレーティングシステムは、単一の CPU 上
を行った。その結果、現在まで提案された種々のスケ
において時分割制御を行うことで複数のプロセスの並
ジューラの中では、最新の O(1) スケジューラが良好な
行実行を実現してきた。このとき、
「CPU 性能は一定で
結果を示すことが明らかとなった。
ある」という仮定のもと、各プロセスの使用した CPU
また、様々なスケジューラの評価結果を報告すると
利用時間は、実際に各プロセスが CPU で走行していた
ともに、その問題点についても指摘を行った。特に、
細切れの時間を合計することで計算していた。例えば、
O(1) スケジューラを実装したカーネルは、SMP システ
ム上でのプロセスのスケジューリングに大きな偏りを
持つ、という問題点が存在することを明らかにした。
ピーク性能という観点からすれば、既存のスケジュー
ラの中で O(1) スケジューラが最も有力な選択肢とな
るが、性能のみにとらわれず、上記問題点にも留意し
て、サーバマシンのハードウェア構成や使用目的に応
じて他のスケジューラを柔軟に選択することも必要で
ある。
加えて、最新の CPU アーキテクチャである HyperThreading 機能を搭載した CPU についても評価を行っ
大型計算機上で CPU 時間に応じて課金するシステムが
これによって構築されていた。しかし、Hyper-Threading
機能を搭載した CPU を利用した場合、他スレッドが
動作しているかどうか、あるいはマイクロアーキテク
チャレベルで計算資源が競合しているかどうかで動的
に CPU 性能が変動することとなる。この結果、単純に
上記のような仮定を適用することができなくなる。ま
た、プロセススケジューラの観点からすれば、ある一
定の実時間タイムスライスを単位としてスケジューリ
ングを行ったとき、想定したタイムスライスに見合っ
Linux Conference 2002 「エンタープライズ向けプロセススケジューラの評価および改良」
た。ここでは、既存の SMP 向けのスケジューリング
ポリシーを単純に適用するだけでは、CPU 本来の性能
を引き出すことはできないことを述べた。我々の行っ
た簡単な改良により、テストプログラムの性能が最大
1.5 倍向上した。
今後は、本論文で述べたスケジューラのいくつかの
問題点について、検討および改良を引き続き行う予定
である。
参考文献
[1] “Linux Scalability Effort Project”,
http://sourceforge.net/projects/lse
[2] “Java Technology, Threads, and Scheduling in Linux”, R.
Bryant and B. Hartner, Java Technology Update, 4(1), January 2000.
[3] “Enhancing Linux Scheduler Scalability”, Mike Kravetz,
Hubertus Franke, Shailabh Nagar, Rajan Ravindran, 5th
Annual Linux Showcase & Conference, November 2001.
[4] “Scalable Linux Scheduling”, S.Molloy and P. Honeyman,
In CITI Technical Report 01-7, University of Michigan,
May 2001.
[5] “Speeding Up Kernel Scheduler by Reducing Cache
Misses”, Shuji YAMAMURA, Akira HIRAI, Mitsuru
SATO, Masao YAMAMOTO, Akira NARUSE, and
Kouichi KUMON, In Proc. of the USENIX 2002 Annual
Technical Conf. FREENIX Track, pp.275–285, June 2002.
[6] “[announce]
[patch]
ultra-scalable
O(1)
SMP
and UP scheduler”, Linux kernel mailing list,
http://marc.theaimsgroup.com/?l=linux-kernel&m=10101
0394225604&w=2
[7] “Linux カーネル 2.5 最新開発動向”, 後藤正徳,
http://www.atmarkit.co.jp/flinux/special/kernel25/kernel2
5b.html.
[8] “システム・チューニングで Linux システムを高速化す
る”, 日経 Linux 2002 年 4 月号, pp.56–57.
[9] “GATES（PC サーバ用汎用メモリアクセストレースシ
ステム）の開発”. 佐藤充, 成瀬彰, 久門耕一, 情報処理
学会第 59 回全国大会講演論文集, 1999 年 9 月.
[10] “詳解 LINUX カーネル”, Daniel P. Bovet, Marco Cesati
著, 高橋浩和, 早川仁監訳, 岡島順治郎, 田宮まや, 三
浦広志訳, オライリー・ジャパン, 2001 年 7 月.
[11] “Solaris Internals Core Kernel Architecture”, Jim Mauro
and Richard McDougall, SUN MICROSYSTEMS
PRESS.
[12] “The Slab Allocator: An Object-Caching Kernel Memory
Allocator”, Jeff Bonwick, In USENIX Conference Proceedings, pp 87-98, 1994.
[13] “WebBench Homepage”, http://etestinglabs.com/benchmarks/webbench/webbench.asp
[14] “Linux Benchmark Suite Homepage”,
http://lbs.sourceforge.net/
[15] “Lockmeter: Highly-Informative Instrumentation for Spin
Locks in the Linux Kernel”, Ray Bryant, John Hawkes, 4th
Annual Atlanta Linux Showcase & Conference, October
2000.
14
[16] “Hyper-Threading Technology”, http://developer.intel
.com/technology/hyperthread/
[17] “Hyper-Threading Technology Architecture and Microarchitecture”, Deborah T. Marr, et al., Intel Technology Journal, Volume. 6, Issue. 1, February 2002.
[18] “Simultaneous Multithreading: Maximizing On-Chip Parallelism”, Dean M. Tullsen, Susan J. Eggers, and Henry M.
Levy, In Proc. of 22nd Annual International Symposium on
Computer Architecture, pp. 392–403, June 1995.
[19] “An elementary processor architecture with simultaneous
instruction issuing from multiple threads”, H. Hirata, K.
Kimura, S. Nagamine, Y. Mochizuki, A. Nishimura, Y.
Nakase, and T. Nishizawa, In Proc. of 19th Annual International Symposium on Computer Architecture, pp. 136–
145, May 1992.

Download Report