JP2003330873A - 情報処理装置及び入出力方法並びにプログラム - Google Patents

Abstract

(57)【要約】 【課題】 データの多重化を行うとともに割り込み処理
にかかる処理時間を低減して、入出力の高速化を図る。 【解決手段】 入出力動作を要求するプロセス３１と、
プロセス３１からの要求に基づいて入出力動作を行うア
ダプタ６と、アダプタ６が入出力動作を行っている間は
プロセス３１の状態を実行待ちにするスケジューラ４１
とを備え、アダプタ６の入出力動作が完了したときに、
この動作完了を待っているプロセス３１の状態をアダプ
タ６が実行可能状態に変更することで、入出力動作を要
求したプロセス３１の実行を再開させる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は入出力アダプタ、特
にディスク装置、ネットワーク等を、コンピュータ等に
接続し、そのディスク装置やネットワークに使用するプ
ロトコルを処理するアダプタに関する。

【０００２】

【従来の技術】ディスク接続方法やネットワークは、複
数の種類が存在し、イーサネット（登録商標）、Ｆｉｂ
ｒｅ Ｃｈａｎｎｅｌ、ＡＴＭ、パラレルＳＣＳＩがそ
の例である。

【０００３】これらのディスク接続方法やネットワーク
をホスト（コンピュータ）等の情報処理装置に接続する
とき、ホストの内部Ｉ／Ｏバスと、ディスク接続方法や
ネットワークを結ぶアダプタを使用する。

【０００４】パーソナルコンピュータにおいては、ＰＣ
Ｉバスとイーサネットを結ぶネットワークアダプタがそ
のアダプタの一例である（ＰＣＩバスのコネクタに接続
するカードという形式のアダプタが良くあるが、マザー
ボードにこれらのコンポーネントを直接組み付ける例も
あり、この場合にもアダプタと呼ぶ）。

【０００５】図６を使用してコンピュータシステムのア
ダプタ、そしてオペレーティングシステム（以下、Ｏ
Ｓ）のカーネルとプロセスの動作を説明する。

【０００６】本願明細書では、説明を分かりやすくする
ためにネットワークアダプタ、そしてネットワークでの
通信に極めて一般的に使用されているＴＣＰ／ＩＰプロ
トコル（W. Richard Stevens, “UNIX Network Program
ming,” Prentice Hall, U.S.A., 1990, ISBN 0-13-949
876-1参照、以下参考文献１と呼ぶ）の通信の場合を中
心に説明する。そして、ＴＣＰ／ＩＰで通信するための
ソケットＡＰＩ（Application Programming Interfac
e、プロセスがコンピュータやオペレーティングシステ
ムのある機能を用いるために呼び出す関数の集合）を例
に使用する（参考文献１参照）。また、ＯＳとしてはＬ
ｉｎｕｘカーネル（D. P. Bovet, M. Cesati, “Unders
tanding the Linux Kernel,” O’Reilly & Associate
s, 2001, ISBN 0-596-00002-2参照、以下参考文献２と
呼ぶ）を例にすることがある。なお、本発明においては
ネットワークアダプタ、ＴＣＰ／ＩＰプロトコル、ソケ
ットＡＰＩやＬｉｎｕｘカーネルに制限されるものでは
ない。

【０００７】まず、図６の場合、ホスト１の複数のプロ
セス（プログラム）３１、３２がアダプタ２を使用して
通信する（図６と今後の図にネットワーク上の通信相手
を図示しない）。カーネル４は、アダプタ２を制御し、
プロセス３１、３２のデータと制御の多重化（マルチプ
レクシング、デマルチプレクシング）をする。次にこの
多重化を説明する。

【０００８】まず、データの多重化について説明する。
アダプタ２は複数のプロセス３１、３２のデータをまと
めて送受信するため、カーネル４はバッファ４５を介し
て複数プロセス３１、３２とアダプタ２の間でデータの
多重化を行う。まず、受信処理について説明する。アダ
プタ２はネットワークからパケットを受信したとき、そ
のパケットをカーネル４のバッファ４５に書き込む（ア
ダプタは、ＤＭＡで主記憶の書き込み／読み出しができ
る）。

【０００９】そして、アダプタ２が受信完了のときに割
り込みを起こし、その割り込みを、このアダプタ２の割
り込み処理４７のコードが処理し、デバイスドライバ４
６を呼び出す。デバイスドライバ４６がバッファ４５を
読み出し、パケットの通信プロトコルを調べ、このプロ
トコル（この例ではＴＣＰ／ＩＰ）のプロトコル処理４
３を呼び出す。

【００１０】ＴＣＰ／ＩＰでは、予め確立された論理接
続の上でデータを通信する。プロトコル処理４３はＴＣ
Ｐ／ＩＰ処理を行うために、通信の状態の管理と、論理
接続とプロセスとの連携などを記録するプロトコル処理
表４４を持つ。プロトコル処理４３は、受信したデータ
の宛先となるプロセス３１、３２を調べ、このデータを
このプロセス３１、３２のバッファ３３、３４にそれぞ
れコピーし、受信したデータのバッファ４５の領域を開
放し、受信処理を完了する。

【００１１】送信処理はほぼ逆方向の処理を行う。ま
ず、プロセス３１、３２が送信データ３３、３４を指定
してプロトコル処理４３を呼び出す。プロトコル処理４
３がそのデータ３３、３４をバッファ４５にコピーし、
このバッファ４５上でパケットを組み立て、デバイスド
ライバ４６を呼び出す。デバイスドライバ４６がアダプ
タ２を制御し、パケットを送信させる。送信が完了した
とき、アダプタ２が割り込みを起こし、この割り込みを
割り込み処理４７と、デバイスドライバ４６が処理し、
デバイスドライバ４６が送信されたパケットのバッファ
４５の領域を開放する。

【００１２】次にプロセス制御の多重化を説明する。図
６において、アダプタ２は複数のプロセス３１、３２に
関する割り込みをまとめて起こすため、カーネル４がそ
の割り込みを各プロセス３１、３２のプロセス制御への
多重化も行う（この処理は普段「多重化」と呼ばれない
が、データの多重化との類似を指摘するためにこの明細
書はこの用語を使用する）。

【００１３】プロセス制御は主に、次に説明するプロセ
ス状態の変更を行う。各プロセスは複数の状態があり、
「実行中」（どれかのＣＰＵがこのプロセスを実行して
いるという状態）、「実行可能」（プロセスが実行でき
るが、ＣＰＵが実行していない状態）、「Ｉ／Ｏ待ち」
（プロセスが送受信などの完了を待っている状態）がそ
の例である（参考文献２参考。Ｌｉｎｕｘのプロセスは
これらの状態があるが、Ｌｉｎｕｘのtask#structの状
態は上記の３つの状態に一対一対応しない）。

【００１４】カーネル４が送受信時に各プロセス３１、
３２の状態を管理し、プロセステーブル４２に状態を記
録する。

【００１５】図８に受信処理のタイムチャートを例にす
る。プロセス３１、３２がソケットＡＰＩのブロッキン
グ呼び出し（データ受信完了まで待つ）を使用したと
き、カーネル４のプロトコル処理４３が呼ばれる（８０
０）。プロトコル処理４３ではデータが受信されていな
い場合、カーネル４のスケジューラ４１を呼び出し（８
０１）プロセス３１、３２を実行中状態からＩ／Ｏ待ち
状態に変更する。

【００１６】アダプタ２はデータ受信完了のときに割り
込みを起こす（８０２）。割り込み処理４７、デバイス
ドライバ４６とプロトコル処理４３が呼び出され（８０
３、８０４）、プロトコル処理４３は上記受信処理の中
でどのプロセス３１、３２がこの受信に対応するかを調
べ、状態変更が必要である場合にスケジューラ４１を呼
び出す（８０５）。スケジューラ４１がデータを送受信
したプロセス３１、３２を実行可能状態にする。

【００１７】その後（実行可能状態になった直後か、一
つあるいは複数のタイマー５割込み（後述）の後）、こ
のプロセス３１、３２が実行中状態となり（８０６）、
受信処理を完了する（８０７）。

【００１８】なお、送受信に関わらず、タイマー５が定
期的に割り込みを起こし（Ｌｉｎｕｘでは１００Ｈｚ、
参考文献１の１４０ページ参照）、タイマー処理４８の
後にスケジューラが呼ばれ（参考文献１の１３３及び１
４２ページ参照）、必要があればスケジューラ４１が実
行可能と実行中プロセス３１、３２の中のどれを実行
中、実行可能にするかを選択する。この処理でカーネル
がタイムシェアリングを実現する。

【００１９】近年、ネットワーク性能がサーバ処理能力
を大きく上回って向上してきた結果、ＴＣＰ／ＩＰプロ
トコルの処理がボトルネックとして顕在化してきた。

【００２０】その対策として、アダプタでのプロトコル
処理の２つの方式、すなわちＴＣＰ／ＩＰのハードウェ
ア化（J. Hufferd, “The Outboarding of TCP/IP," e-
Commerce Infrastructure Technology Conference and
Tradeshow, February 2001,Monterey, U.S.A.参照）
と、論理接続などのＴＣＰ／ＩＰ相当の機能を独自プロ
トコルで実現するＩｎｆｉｎｉＢａｎｄネットワーク
（InfiniBand Architecture Specification Volume 1 R
elease 1.0.a参照）が開発されてきた。

【００２１】図７にＩｎｆｉｎｉＢａｎｄアダプタを例
にしてプロトコルを処理するアダプタ６００を説明す
る。

【００２２】このアダプタ６００は、論理接続の通信エ
ンドポイント６１０〜６３０で、各論理接続の処理と通
信状態の管理をする（ＩｎｆｉｎｉＢａｎｄでは、この
通信エンドポイントをＱｕｅｕｅ Ｐａｉｒと呼び、以
下ＱＰと略す）。

【００２３】プロセス３１、３２がプロトコル処理４９
とデバイスドライバ５０を介して論理接続を確立する
が、確立後にカーネル４を介さないでエンドポイント６
１０〜６３０を直接アクセスする（プロトコル処理４
９、プロトコル処理表４０、デバイスドライバ５０はプ
ロトコル処理４３、プロトコル処理表４４、デバイスド
ライバ４６と同等であるが、後者のプロトコル処理を含
めず、接続管理の機能のみを含む）。

【００２４】そして、アダプタ６００はプロセス３１、
３２のデータ３３、３４を直接送受信するために複数の
通信エンドポイント６１０〜６３０の多重処理６４を行
う。このため、アダプタ６００の場合、カーネル４でな
く、アダプタ６００がデータの多重化を行う。

【００２５】ＩｎｆｉｎｉＢａｎｄアダプタ６００を直
接駆動するにはソケットと異なったＡＰＩを使用する
が、ＩｎｆｉｎｉＢａｎｄ向けＡＰＩにもブロッキング
呼び出しが存在すると考えられる（これらのＡＰＩは現
在規格化中である）。

【００２６】上記図７のＩｎｆｉｎｉＢａｎｄアダプタ
６００における処理を、上記図８のタイムチャートを用
いて説明すると、アダプタ６００がデータ送受信のプロ
トコル処理をするため、ブロッキング呼び出し（８０
０）のときにプロトコル処理４９がスケジューラ４１の
呼び出しをする（変形例としてここでは、特別なシステ
ムコールを設ければ、プロセス３１、３２が直接スケジ
ューラを呼べる）。送受信完了のときにアダプタ６００
が割込みを起こす（８０２）。

【００２７】

【発明が解決しようとする課題】上記図７の従来例にお
いては、プロトコルを処理するアダプタ６００は、デー
タ送受信時にカーネル４をバイパスして、プロトコル処
理４３のバイパス、そしてプロセス３１、３２のバッフ
ァ３３、３４とバッファ４５とのデータコピーをなくす
ことなどにより、ＣＰＵ負荷を削減し、通常のアダプタ
２（図６）のボトルネックの一部を解決する。

【００２８】しかしながら、プロトコルを処理するアダ
プタ６００がデータの多重化を処理する一方、制御の多
重化を行っていない。例えば、プロセス３１、３２がソ
ケットＡＰＩのブロッキング受信呼び出しを使用したと
き、割り込みに関する処理、すなわち割り込み処理４
７、デバイスドライバ５０、プロトコル処理４９、スケ
ジューラ４１の処理（８０２〜８０５）が必要である。
その結果、データ通信がカーネル４をバイパスする一
方、制御はカーネル４をバイパスしないため、ボトルネ
ックの一部が残ってしまう。

【００２９】つまり、アダプタ６００は送受信が完了す
ると、割り込み処理４７を行って、プロトコル処理４
９、スケジューラ４１を呼び出し、データ送受信待ち
（Ｉ／Ｏ待ち）となっていたプロセス３１、３２を実行
可能にする訳であるが、図７で示したように、複数のエ
ンドポイント６１０〜６３０で送受信が完了する度に割
り込み処理を行う必要があるため、各プロセスが「Ｉ／
Ｏ待ち」から「実行可能」となるまでに処理時間を要
し、このためデータの多重化のみでは、アダプタ６００
における通信処理のオーバーヘッドを解消できない、と
いう問題があった。

【００３０】そこで本発明は、上記問題点に鑑みてなさ
れたもので、データの多重化を行うとともに割り込み処
理にかかる時間を低減して、入出力の高速化を図ること
を目的とする。

【００３１】

【課題を解決するための手段】本発明は、入出力動作を
要求する処理と、この処理からの要求に基づいて入出力
動作を行うアダプタと、前記アダプタが入出力動作を行
っている間は前記処理の状態を実行待ちにするスケジュ
ール手段とを備えて、前記アダプタの入出力動作が完了
したことに基づいて前記処理の状態を実行可能に変更す
る入出力方法において、前記アダプタの入出力動作が完
了したときに、この動作完了を待っている処理の状態を
アダプタが実行可能状態に変更することで、入出力動作
を要求した処理の実行を再開させる。

【００３２】すなわち、プロセス３１、３２がブロッキ
ング呼び出しをし、この呼び出しに関する送受信が完了
したとき、アダプタ６がこのプロセス３１、３２のプロ
セステーブル４２の状態を実行可能にする。このため、
割り込みとカーネル４の処理なしでプロセス３１、３２
の状態を変更できる。このプロセス３１、３２はその後
のタイマー処理４８によるスケジューラ４１の実行時に
実行中になる。

【００３３】一方、ホスト１にアイドル状態のＣＰＵが
あれば、性能を向上するために送受信完了時に実行可能
になったプロセス３１、３２をすぐに実行中にする必要
がある。このため、アイドル状態のＣＰＵがあれば割り
込みを起こす。割り込み処理の後にスケジューラ４１が
呼ばれ、このプロセス３１、３２が実行中になる。

【００３４】

【発明の効果】したがって本発明は、入出力動作が要求
されると、アダプタによる入出力動作を実行するととも
に、要求した処理を実行待ち（Ｉ／Ｏ待ち）状態にす
る。そして、アダプタは入出力動作が完了すると、処理
の状態を直接的に実行待ち状態から実行可能状態へ変更
するため、入出力動作が完了した時点から処理が再び実
行されるまでの処理時間を短縮でき、入出力処理の高効
率化による高速化を図ることが可能となるのである。

【００３５】

【発明の実施の形態】以下、本発明の一実施形態を添付
図面に基づいて説明する。

【００３６】図１は、前記従来例の図７に示したＩｎｆ
ｉｎｉＢａｎｄアダプタに、本発明を適用した一例を示
す。

【００３７】ホスト（コンピュータ）１のオペレーティ
ングシステム上で稼働する複数のプロセス３１、３２
（アプリケーション）が、ＩｎｆｉｎｉＢａｎｄアダプ
タ６を使用して、ホスト１の外部とネットワーク７を介
して通信するもので、オペレーティングシステム（以
下、ＯＳ）のカーネル４は、ＩｎｆｉｎｉＢａｎｄアダ
プタ６を制御して、プロセス３１、３２のデータ３３、
３４と制御の多重化（マルチプレクシング、デマルチプ
レクシング）を行う。

【００３８】ここで、ホスト１のハードウェア構成の概
略を図２に示す。

【００３９】ホスト１には、複数のＣＰＵ（プロセッ
サ）１０１、１０２がＣＰＵバス１０３を介してメモリ
ーコントローラ１０４に接続され、また、メモリーバス
１０５を介してメモリーコントローラ１０４はメモリー
１０６に接続されており、ＣＰＵ１０１、１０２または
他のデバイスからメモリー１０６のアクセスを行う。

【００４０】さらに、メモリーコントローラ１０４は、
内部Ｉ／Ｏバス１０７を介してＩｎｆｉｎｉＢａｎｄア
ダプタ６に接続され、ＣＰＵ１０１、１０２は外部のネ
ットワーク７と通信可能となる。

【００４１】なお、メモリーコントローラ１０４には、
割り込みコントローラなどが含まれ、メモリー１０６が
主記憶となる。また、ＣＰＵ１０１、１０２は論理的に
独立している仮想プロセッサで構成してもよい。

【００４２】図１において、アダプタ６は、論理接続の
通信エンドポイント（ＱｕｅｕｅＰａｉｒで、以下Ｑ
Ｐ）６１〜６３で、各論理接続の処理と通信状態の管理
をする。

【００４３】プロセス３１、３２がプロトコル処理４９
とデバイスドライバ５０を介して論理接続を確立する
が、論理接続の確立後にはカーネル４を介さないでエン
ドポイント６１〜６３を直接アクセスする。

【００４４】そして、アダプタ６はプロセス３１、３２
のデータ３３、３４を直接送受信するために複数の通信
エンドポイント６１〜６３の多重処理６４を行う。この
ため、ＩｎｆｉｎｉＢａｎｄアダプタ６の場合、カーネ
ル４でなく、ＩｎｆｉｎｉＢａｎｄアダプタ６がデータ
の多重化を行う。

【００４５】オペレーティングシステムのプロセス制御
は主に、次に説明するプロセス状態の変更を行う。各プ
ロセスは複数の状態があり、「実行中」（どれかのＣＰ
Ｕがこのプロセスを実行しているという状態）、「実行
可能」（プロセスが実行できるが、ＣＰＵが実行してい
ない状態）、「Ｉ／Ｏ待ち」（プロセスが送受信などの
完了を待っている状態）がその例である（参考文献２参
考。Ｌｉｎｕｘのプロセスはこれらの状態があるが、Ｌ
ｉｎｕｘのtask#structの状態は上記の３つの状態に一
対一対応しない）。

【００４６】ここで、ＯＳ（ここではＬｉｎｕｘ）のカ
ーネル４には、プロセス３１、３２とアダプタ６の論理
接続を確立するプロトコル処理４９、デバイスドライバ
５０を備え、また、タイマー５によるタイマー処理４８
または割り込み処理４７によってプロセス３１、３２を
制御するスケジューラ４１を備えている。

【００４７】さらに、スケジューラ４１のテーブル４２
は、アダプタ６のエンドポイント６１〜６３にそれぞれ
設けた状態変更機構６５〜６７により、直接書き込み可
能に構成される。

【００４８】また、アイドル状態のＣＰＵがあるか否か
を示す稼働中フラグ６８が設けられ、この稼働中フラグ
６８は、スケジューラ４１によって設定され、アダプタ
６からの割り込み要求をＣＰＵの稼働状態に応じて制御
可能とする。

【００４９】次に、各エンドポイント６１〜６３に設け
た、状態変更機構６５〜６７について説明する。

【００５０】プロトコル処理４９が、あるエンドポイン
ト６１〜６３をあるプロセス３１、３２にアロケート
し、このエンドポイント６１〜６３の論理接続を確立し
たとき、これらエンドポイント６１〜６３の状態変更機
構６５〜６７に、プロセステーブル４２上でこれらプロ
セス３１、３２の状態を示すエントリのアドレスを登録
する。これにより、各エンドポイントの状態変更機構６
５〜６７は、エンドポイント毎の論理接続に対応するプ
ロセステーブル４２上のエントリへ書き込み可能とな
る。

【００５１】そして、この状態変更機構６５〜６７への
エントリ登録時に、プロセステーブル４２の各エントリ
のフィールド上で「実行可能」を示す値とバイト幅を状
態変更機構６５〜６７に登録する。なお、スケジューラ
４１のプロセステーブル４２は、主記憶上の所定の領域
に予め設定された記憶領域である。

【００５２】また、論理接続上のデータ送受信時に、プ
ロセス３１、３２がブロッキング呼び出しを使用したと
きに、エンドポイント６１〜６３を起動して送受信を開
始する中で、送受信完了時に状態を変更することを要求
する（前記従来例と同じく、起動の処理を、標準ＡＰＩ
の下にあるアダプタ６関連の通信ライブラリが実現す
る）。

【００５３】この状態変更機構６５〜６７の動作につい
て、図３のタイムチャートを参照しながら説明する。

【００５４】そして、プロセス３１、３２がプロトコル
処理４９を呼び出し（図３の８００）、プロトコル処理
４９がこのプロセスの状態をＩ／Ｏ待ちにし、スケジュ
ーラ４１を呼び出す（８０１）（これで、実行可能のプ
ロセス３１、３２があれば、これらのどれかが実行中に
なる）。

【００５５】送受信が完了したときに、エンドポイント
６１〜６３が状態変更機構６５〜６７に登録されたエン
トリに基づいて、実行可能を示す値をＤＭＡにより主記
憶のプロセステーブル４２に書き込み、プロセス３１、
３２の状態をＩ／Ｏ待ちから実行可能に変更する（図１
では例として、エンドポイント６２の状態変更機構６６
からのプロセステーブル４２への書き込みを矢印で示
す）。一つあるいは複数のタイマー５割込みの後、この
プロセス３１、３２が実行中になり（８０６）、ブロッ
キング呼び出しの処理を完了する（８０７）。

【００５６】エンドポイントの送受信完了時に、全ての
ＣＰＵがビジーであれば、スケジューラを呼び出しても
ホスト１の性能が向上しない（実行中のプロセスのタイ
ムカンタムが終わっておらず、プロセス３１、３２の状
態が変更されないからである）。このため、状態変更機
構６５〜６７からプロセステーブル４２への書き込みで
実行可能となったプロセスはその後のタイマー処理４８
のときに実行中になる。

【００５７】一方、アイドル状態のＣＰＵがあれば、ホ
スト１の性能を向上するためにすぐにスケジューラを呼
び出し、実行可能となったプロセスを実行中にする必要
がある。

【００５８】その結果、ＣＰＵのビジー状態により割り
込み制御（起こすか否か）が必要である。この割り込み
の制御を行うために、アイドル状態のＣＰＵがあるか否
かを示すフラグとして上記稼動中フラグ６８が設けら
れ、スケジューラ４１が稼動中フラグ６８を設定する。

【００５９】アイドル状態のＣＰＵがある場合、稼動中
フラグ６８はアダプタ６からの割り込みをイネーブル
（許可）し、ない場合に割り込みをディスエーブル（禁
止）する（但し、エラーなどの例外処理に関連する割り
込みを抑止しない。これら例外処理については稼動中フ
ラグ６８で監視せずに、別の割り込みライン（図示せ
ず）を使用することが望ましい）。

【００６０】次に、図４には上記割り込み処理の処理フ
ローを示す。

【００６１】アダプタ６は、状態変更機構６５〜６７に
よりプロセステーブル４２を変更した後に割り込みを起
こし、割り込み処理４７を起動する（８０２）。

【００６２】割り込み処理４７がアダプタ６の状態を調
べ、この割り込みがプロセス３１〜３２の状態の変更を
目的とする情報を取得したら、デバイスドライバ５０を
呼ぶ必要がないことを判明する。これで、スケジューラ
４１が呼ばれ（８０８）、対象となるプロセス３１〜３
２が実行可能になり（８０６）、ブロッキング呼び出し
の処理を完了する（８０７）。

【００６３】なお、この図４では、一般的な処理の流れ
として割込み処理４７から直接スケジューラ４１を呼ぶ
ことを示している。但し、Ｌｉｎｕｘでは割込み処理４
７から直接スケジューラ４１を呼べないため、ボトムハ
ーフ等の処理を延期する方法を使用して間接的にスケジ
ューラ４１を呼ぶ。

【００６４】こうして、アダプタ６がエンドポイント６
１〜６３の論理接続を確立したとき、プロセステーブル
４２上で論理接続を確立したプロセスに対応するエント
リのアドレスを状態変更機構６５〜６７へ登録し、その
後、送受信を行う。そして、送受信完了時には、アダプ
タ６の状態変更機構６５〜６７は、送受信に対応したプ
ロセステーブル４２上のエントリを、「Ｉ／Ｏ待ち」か
ら「実行可能」に更新し、その後、アダプタ６が割り込
みをかけることで、直接スケジューラ４１を呼ぶことが
可能となる。

【００６５】これにより、前記従来例では、図８で示し
たように、割り込み処理４７は、デバイスドライバ５
０、プロトコル処理４９、スケジューラ４１の順で、順
次処理を行っていたのに比して、本願発明によれば、割
り込み処理４７から直接スケジューラ４１を呼ぶように
したため、前記従来例の図８におけるステップ８０３、
８０４、８０５が不要になって、これらの処理に要する
オーバーヘッドを低減でき、送受信完了からプロセスの
実行までの時間を短縮することが可能となり、この結
果、プロセス３１、３２とアダプタ６間の通信（または
入出力）処理の高速化を図ることが可能となるのであ
る。

【００６６】本発明は、上記実施形態あるいはその変形
例に限定されるものではなく、以下に例示する変形例あ
るいは他の変形例によっても実現可能であることは言う
までもない。また、上記複数の実施の形態あるいはその
変形例として記載の技術あるいは以下の変形例の組み合
わせによっても実現できる。 （変形例１）上記図１では、プロトコル処理表４０がプ
ロトコル処理の情報を持つ。しかし、実際のカーネル４
ではこの情報が複数の表として実現されることもある
が、本発明はこの場合にでも実現できる。 （変形例２）本発明はＩｎｆｉｎｉＢａｎｄアダプタ６
に制限されておらず、他のプロトコル（ＴＣＰ／ＩＰ
等）を処理するアダプタにも使用できる。

【００６７】ＴＣＰ／ＩＰを処理するアダプタの場合に
は、個別にインプリメントされたエンドポイント６１〜
６３がない場合が考えられる。しかし、このアダプタが
各ＴＣＰ／ＩＰ論理接続の状態を管理するため、この管
理の中に状態変更機構６５〜６７相当の機能を追加する
ことで本発明をインプリメントできる。

【００６８】そして、ＩｎｆｉｎｉＢａｎｄでは各送受
信操作の完了が明確である一方、ＴＣＰ／ＩＰはストリ
ーミングプロトコルであるため、データが連続に流れ、
プロセス３１、３２の送受信の完了はプロトコルレベル
から見えない。このため、一つのパケットの送受信、ま
たはプロセス３１、３２が設定した最低限のデータ量な
どを送受信の完了の基準とする。 （変形例３）本発明は、上記ＩｎｆｉｎｉＢａｎｄやＴ
ＣＰ／ＩＰのようなネットワークアダプタだけでなく、
ディスクや他のアダプタにも使用できる。例えば、ディ
スクアダプタは従来、データを入出力（書き込み／読み
出し）動作を起動するときに、書き込み／読み出しを対
象とする主記憶アドレスとディスクブロックを指定し、
これらの間で入出力が行われる。

【００６９】この従来のディスクアダプタに本発明を適
用するために、上記の入出力動作を起動するための情報
に状態変更機構６５〜６７相当の情報（書き込みアドレ
スと値とバイト幅）を追加し、そしてアダプタにこの状
態変更機構６５〜６７相当の情報を送受信完了時にカー
ネル４側のプロセステーブル４２へ書き込むための機能
を追加すればよい。 （変形例４）以上の説明では、論理接続確立のときに
「実行可能」を示す値とそのバイト幅をアダプタ６に登
録する例を示した。しかし、アダプタ６に「実行可能」
を示す情報を登録するタイミングは上記に限定されるも
のではなく、例えば、アダプタ６の初期化のときに登録
してもよい。そして、その値を各状態変更機構６５〜６
７に登録することでなく、アダプタ全体にその値を登録
する一つの機構を追加することも考えられる。 （変形例５）上記図１において、アダプタ６の状態変更
機構６５〜６７が書き込み先を、プロセステーブル４２
でなく、図５に示す別の表（表５２）にすることが考え
られる。

【００７０】この形態は、カーネル４の変更を削減し、
ハードウェアにプロセステーブル４２を直接アクセスさ
せないため、カーネル４に関する開発工数と信頼性の面
では望ましい。この場合、カーネル４の状態変更タスク
５１がその表の値を定期的に調べ、アダプタ６からの書
き込みが行なわれた場合に、対象とするプロセスのプロ
セステーブル４２の状態を変更する。

【００７１】そして、アイドルＣＰＵがあり、割り込み
を起こした場合に、割り込み処理４７からスケジューラ
４１を直接呼ばない。代わりに、状態変更タスク５１を
呼び、状態変更タスク５１がプロセステーブル４２を変
更し、スケジューラ４１を呼ぶ手順になる。

【００７２】状態変更タスク５１が表５２を定期的に調
べる方法として、例えばＬｉｎｕｘではＴａｓｋ Ｑｕ
ｅｕｅを使用することが考えられる（A. Rubini, “Lin
ux Device Drivers," O'Reilly & Associates, ISBN 1-
56592-292-1参照）。アダプタ６を初期化したときにtq#
timerタスクキューに書き込みを調べるタスクを入れ、
そしてこの状態変更タスク５１が、実行時に自分をこの
タスクキューに再び追加することで、書き込みを調べる
タスクがタイマー５割り込み毎に実行される。

【００７３】本変形例の場合、プロセステーブル４２に
は、書き込むアドレスと値とバイト幅ではなく、プロセ
ス識別子（プロセス番号など）を使用することが考えら
れる。なお、表５２のデータ構造として、循環キューが
考えられる。循環キューの場合、アダプタ６が循環キュ
ーに、状態変更するプロセス３１、３２の情報（識別子
等）を書き込み、定期的にその情報を調べる状態変更タ
スク５１がその情報を消費する。状態変更タスク５１が
消費した分をアダプタ６か状態変更機構６６に知らせる
（アダプタ６全体に一つの表５２のみを設けた場合はア
ダプタ６に、状態変更機構６６毎に表５２を設けた場合
に状態変更機構６６に知らせる）。

【００７４】（変形例６）以上の実施形態と変形例に、
アダプタ６が主記憶にプロセス３１、３２に関する情報
を書き込むことで、直接的か間接的に対象となるプロセ
スの状態を変更する。代わりに、図５に示すとおり、主
記憶にないキュー５３を設け、アダプタ６が状態変更す
るプロセス３１、３２の情報（識別子など）をこのキュ
ー５３に追加し、定期的にこのキュー５３の情報を調べ
る状態変更タスク５１（上記変形例５参照）がこの情報
を読み出す方法が考えられる。

【００７５】このキュー５３は、アダプタの内部の記憶
手段（または記憶域）、または割り込みコントローラの
内部の記憶手段（記憶域）などが考えられる。

【００７６】（変形例７）上記実施形態に示した稼動中
フラグ６８は、ハードウェアまたはソフトウェアの何れ
かで実現できる。まず、ハードウェアによる実現方法と
しては、アダプタ６の一部、そしてホスト１の回路（割
り込みコントローラ回路の内部など）が考えられる。

【００７７】次に、ソフトウェアによる実現方法として
は、ホスト１の割り込みコントローラを設定して、アダ
プタ６からの割り込みをイネーブル／抑止することが考
えられる。

【００７８】（変形例８）以上の説明では説明や図を分
かりやすくするために、アダプタ６は、上記図２で示し
たように、ホスト１の内部Ｉ／Ｏバス１０７とネットワ
ーク７との間のアダプタにしたが、本発明はこの形態に
制限されていない。他の形態の具体例として、Ｉｎｆｉ
ｎｉＢａｎｄと他ネットワークのアダプタが考えられる
（この場合、ＩｎｆｉｎｉＢａｎｄが内部バスの位置付
けを持つ）。そして、アダプタが一つまたは複数の接続
でＩｎｆｉｎｉＢａｎｄのみに接続され、Ｉｎｆｉｎｉ
Ｂａｎｄ上のＴＣＰ／ＩＰを処理する形態も考えられる
（この場合、内部バスと外部ネットワークがＩｎｆｉｎ
ｉＢａｎｄとなる）。

【００７９】（変形例９）以上の説明では説明や図を分
かりやすくするために、ホスト１がコンピュータのよう
な情報処理装置を前提にした。しかし、本発明はこれら
の情報処理装置に制限されておらず、例えばストレージ
装置や、スイッチやルータのようなネットワーク装置、
またはそれらのアダプタにも適用できる。この場合、装
置は組み込み型装置向けオペレーティングシステムを使
用し、このオペレーティングシステムにプロセス３１、
３２という概念がないことがあるが、本発明は各Ｉ／Ｏ
処理の制御に使用できる。

【００８０】（変形例１０）以上の説明では本発明はプ
ロセス３１、３２の状態を制御しているが、本発明はプ
ロセス３１、３２に制限されておらず、各プロセス３
１、３２の中の処理スレッドの制御にも使用できる。

【００８１】なお、本発明を実施するためのプログラム
は、それ単独であるいは他のプログラムと組み合わせ
て、ディスク記憶装置等のプログラム記憶媒体に記憶さ
れた販売することができる。また、本発明を実施するた
めのプログラムは、すでに使用されている通信を行うプ
ログラムに追加される形式のプログラムでもよく、ある
いはその通信用のプログラムの一部を置換する形式のプ
ログラムでも良い。

【００８２】今回開示した実施の形態は、全ての点で例
示であって制限的なものではないと考えられるべきであ
る。本発明の範囲は上記した説明ではなくて特許請求の
範囲によって示され、特許請求の範囲と均等の意味及び
内容の範囲での全ての変更が含まれることが意図され
る。

【図面の簡単な説明】

【図１】本発明の一実施形態を示し、ホストの機能概略
を示すブロック図である。

【図２】同じく、ハードウェアの概略図である。

【図３】アダプタの状態変更機構の動作を示すタイムチ
ャートである。

【図４】アダプタからの割り込み処理を示すタイムチャ
ートである。

【図５】他の実施形態を示し、ホストの機能概略を示す
ブロック図である。

【図６】従来例を示し、ネットワークアダプタを用いた
ホストの機能概略を示すブロック図。

【図７】他の従来例を示し、ＩｎｆｉｎｉＢａｎｄのア
ダプタを用いたホストの機能概略を示すブロック図。

【図８】同じく、従来例を示し、アダプタからの割り込
み処理を示すタイムチャートである。

【符号の説明】

１ ホスト ４ カーネル ６ アダプタ ４１ スケジューラ ４２ プロセステーブル ６１〜６３ エンドポイント ６５〜６７ 状態変更機構

Claims (15)

【特許請求の範囲】
1. 【請求項１】アダプタに入出力動作を要求する処理と、 前記アダプタが入出力動作を行っている間は前記処理の
   状態を実行待ちにするスケジュール手順とを備えて、前
   記アダプタの入出力動作が完了したことに基づいて前記
   処理の状態を実行可能に変更する入出力方法において、 前記アダプタの入出力動作が完了したときに、この動作
   完了を待っている処理の状態をアダプタが実行可能状態
   に変更することを特徴とする入出力方法。
2. 【請求項２】前記スケジュール手順は、所定の記憶域に
   処理毎にアドレスを対応づけて処理の状態を記憶し、 前記アダプタは、入出力動作が完了したときに、前記ス
   ケジュール手順の処理に対応する記憶域へ実行可能状態
   を示す値を書き込むことを特徴とする請求項１に記載の
   入出力方法。
3. 【請求項３】前記アダプタは、前記スケジュール手順に
   記憶される処理に対応したアドレスと実行可能状態を示
   す値を記録する記録手段を有し、 前記入出力動作を行う以前または行うときに前記記録手
   段へ前記処理に対応するアドレス及び前記値を記録する
   ことを特徴とする請求項２に記載の入出力方法。
4. 【請求項４】前記スケジュール手順は、オペレーティン
   グシステムに含まれて、入出力動作の完了を待っている
   前記処理の識別子を記録する手段を有し、 前記オペレーティングシステムは、 前記アダプタの入出力動作が完了したときに前記識別子
   をキューに追加する手順と、 定期的に前記キューの内容を読み出して、追加されてい
   る識別子があった場合には、その識別子に対応する処理
   の状態を実行可能にする手順と、を含むことを特徴とす
   る請求項１に記載の入出力方法。
5. 【請求項５】前記アダプタは、ネットワークプロトコル
   に対して入出力動作を行うとともに、このプロトコルの
   論理接続毎に前記記録手段を有し、 前記入出力動作は論理接続の送受信動作であることを特
   徴とする請求項２ないし請求項４の何れか一つに記載の
   入出力方法。
6. 【請求項６】前記アダプタは、入出力装置アダプタまた
   は入出力装置を接続する手段のアダプタであって、入出
   力操作毎に前記記録手段を有することを特徴とする請求
   項２ないし請求項４の何れか一つに記載の入出力方法。
7. 【請求項７】前記スケジュール手順は、プロセッサの使
   用状態に応じて割り込みを許可または禁止するフラグを
   有し、 前記アダプタは、入出力動作が完了したときに、前記フ
   ラグが許可状態のときに割り込みを発生することを特徴
   とする請求項５または請求項６に記載の入出力方法。
8. 【請求項８】入出力動作を行うアダプタと、 前記アダプタが入出力動作を行っている間は、当該入出
   力動作を要求した処理の状態を実行待ちにするスケジュ
   ール手段とを備え、 前記アダプタは、入出力動作が完了したときに、前記ス
   ケジュール手段に対して、この入出力動作の完了を待っ
   ている処理の状態を実行可能状態に変更することを特徴
   とする情報処理装置。
9. 【請求項９】前記スケジュール手段は、所定の記憶域に
   処理毎にアドレスを対応づけて処理の状態を記憶し、 前記アダプタは、入出力動作が完了したときに、前記ス
   ケジュール手段の処理に対応する記憶域へ実行可能状態
   を示す値を書き込むことを特徴とする請求項８に記載の
   情報処理装置。
10. 【請求項１０】前記アダプタは、前記スケジュール手段
    に記憶される処理に対応するアドレスと実行可能状態を
    示す値を記録する記録手段を備え、 前記入出力動作を行う以前または行うときに前記記録手
    段へ前記処理に対応するアドレス及び前記値を記録する
    ことを特徴とする請求項９に記載の情報処理装置。
11. 【請求項１１】前記スケジュール手段は、オペレーティ
    ングシステムに含まれて、入出力動作の完了を待ってい
    る前記処理の識別子を記録する識別子記録手段を有し、 前記オペレーティングシステムは、 前記アダプタの入出力動作が完了したときに前記識別子
    をキューに追加する手段と、 定期的に前記キューの内容を読み出して、追加されてい
    る識別子があった場合には、その識別子に対応する処理
    の状態を実行可能にする手段と、を含むことを特徴とす
    る請求項８に記載の情報処理装置。
12. 【請求項１２】前記アダプタは、ネットワークプロトコ
    ルに対して入出力動作を行うとともに、このプロトコル
    の論理接続毎に前記記録手段を有し、前記入出力動作は
    論理接続の送受信動作であることを特徴とする請求項９
    ないし請求項１１の何れか一つに記載の情報処理装置。
13. 【請求項１３】前記アダプタは、入出力装置アダプタま
    たは入出力装置を接続する手段のアダプタであって、入
    出力操作毎に前記記録手段を有することを特徴とする請
    求項８ないし請求項１１の何れか一つに記載の情報処理
    装置。
14. 【請求項１４】前記スケジュール手段は、プロセッサの
    使用状態に応じて割り込みを許可または禁止するフラグ
    を有し、 前記アダプタは、入出力動作が完了したときに、前記フ
    ラグが許可状態のときに割り込みを発生する手段を有す
    ることを特徴とする請求項１２または請求項１３に記載
    の情報処理装置。
15. 【請求項１５】アダプタによる入出力処理を伴うプロセ
    スを含む複数のプロセスを所定の順序でコンピュータに
    実行させるプログラムであって、 前記プロセスから入出力処理が要求されたときには、こ
    のプロセスの状態を実行待ち状態に変更する手順と、 この入出力処理を前記アダプタに実行させる手順と、 前記アダプタがプロセスの状態を実行可能状態へ変更し
    たことを検出する手順と、 前記プロセスの状態が実行可能状態となったときには、
    このプロセスの処理を再開する手順と、をコンピュータ
    に実行させることを特徴とするプログラム。