JPH0926929A - 効率のよいデータ転送メカニズムに関する方法及び装置 - Google Patents

Abstract

(57)【要約】 【課題】 アプリケーションが送信側装置のメモリ・オ
ブジェクトから受信側装置にデータを転送できる方法及
び装置の提供。 【解決手段】 アプリケーションは、オペレーティング
・システムが高速バッファとデータを記憶するメモリ・
オブジェクトの間のマッピングを設定するように要求す
る。次に、オペレーティング・システムが、高速バッフ
ァとメモリ・オブジェクトの間にマッピングを設定し、
これによって、アプリケーションは、メモリ・オブジェ
クトのデータを受信側装置に転送するように指示するこ
とが可能になる。従って、受信側装置は、送信側装置に
対する直接メモリ・アクセスを利用して、メモリ・オブ
ジェクトからデータを転送することが可能である。

Description

【発明の詳細な説明】

【０００１】

【発明の技術分野】本発明は、コンピュータ・システム
の分野に関するものである。とりわけ、本発明は、コン
ピュータ・システム内の装置間におけるデータ転送に関
するものである。

【０００２】

【従来の技術】入力／出力（Ｉ／Ｏ）サブシステムは、
オペレーティング・システム（カーネル）の一領域であ
る。この領域は、伝統的に、速度及び効率の向上に関し
て、他の領域よりも注目されなかった。従来、Ｉ／Ｏ装
置は、中央演算処理装置（ＣＰＵ）及びメモリの速度に
比べると低速であり、Ｉ／Ｏシステムに対するソフトウ
ェアの要求はひかえめであり、大部分の機械はユニプロ
セッサである。

【０００３】今日、大部分のオペレーティング・システ
ムのＩ／Ｏサブシステムは、そのＩ／Ｏシステム構築の
基本的仮定の多くがもはや有効ではなくても、旧システ
ムからのパラダイム転換が期待できない。例えば、アプ
リケーションが、ディスク・ファイルからデータを読み
取り、読み取ったデータをネットワーク装置に送る場
合、データは、ネットワーク装置に送信する前に、アプ
リケーションによる修正を受けるものと仮定される。こ
の仮定は、アプリケーションが入力としてデータを受信
し、次に、データに修正を施してから、出力として、そ
の修正済みのデータを送り出すという、データ処理のパ
ラダイムに基づくものである。従って、データが修正を
受けることを予測して、転送すべきデータは、ディスク
・ファイルから、その修正が可能なバッファにコピーさ
れる。ビデオ・サーバの場合、例えば、ビデオ・サーバ
・アプリケーションが、記憶されているビデオ・データ
に修正を加えず、代わりに、データを修正せずに、記憶
されているビデオ・データをネットワーク装置に送るこ
とだけしか指示しなければ、このデータ処理パラダイム
は適用されない。

【０００４】１００ｂａｓｅＴ Ｅｔｈｅｒｎｅｔ及び
ＡＴＭのような、高速ネットワーク媒体の出現は、既存
のＩ／Ｏ及びバッファ管理フレームワークの非効率性に
スポット・ライトを集めるのに役立った。アプリケーシ
ョンとオペレーティング・システム（カーネル）の間に
おけるデータのコピーは、この問題空間における主たる
オーバヘッドを表している。

【０００５】アプリケーションが周辺装置からデータを
検索するための通常のインターフェイスは、データを読
み取るためのシステム・コールを送り出す。この読み取
りインターフェイスは、一般に、ｒｅａｄ（ｄｅｓｃｒ
ｉｐｔｏｒ，ｂｕｆ，ｌｅｎｇｔｈ）のように表すこと
が可能であり、ここで、アプリケーションは、記述子に
よって表される装置／ファイルから充填するサイズ「ｌ
ｅｎｇｔｈ」バイトのバッファ「ｂｕｆ」をシステムに
供給する。同様に、アプリケーションによって周辺装置
にデータを送るために利用される通常のインターフェイ
スは、データを書き込むためのシステム・コールを送り
出す。この書込みインターフェイスは、一般に、ｗｒｉ
ｔｅ（ｄｅｓｃｒｉｐｔｏｒ，ｂｕｔ，ｌｅｎｇｔｈ）
のように表すことが可能であり、ここで、アプリケーシ
ョンは、書き込まれるサイズ「ｌｅｎｇｔｈ」バイトの
バッファ「ｂｕｆ」をシステムに与える。次に、アプリ
ケーションは、書込みコールが復帰するや否や、このバ
ッファを再利用することができる。ファイルまたはフレ
ーム・バッファのようなメモリ・オブジェクトの場合、
アプリケーションは、読み取られる／書き込まれるオブ
ジェクトをメモリに対してマッピングすることも可能で
ある。上記インターフェイスは、一般に、書込み時に
は、ユーザ・バッファからカーネル／装置バッファへの
コピーを必要とし、読み取り時には、カーネル／装置バ
ッファからユーザ・バッファへのコピーを必要とする。

【０００６】通常の読み取り／書込みインターフェイス
に対する改良点は、高速バッファ（ｆｂｕｆ）・インタ
ーフェイスを実施することである。ｆｂｕｆインターフ
ェイスのキーとなる点は、データを取り扱う各種ドメイ
ン（アドレス空間）間におけるバッファの明示的交換で
ある。バッファのキャッシングは、プロセス間通信にお
ける局所性を利用するために実施される。１組のドメイ
ン間におけるデータ交換が済むと、利用されたバッファ
は、同じ組をなすドメイン内における他のデータ交換の
ためにセーブされる。

【０００７】ｔｂｕｆ読み取りインターフェイスは、一
般に、ｒｅａｄ２（ｄｅｓｃｒｉｐｔｏｒ，ｂｕｆ，ｌ
ｅｎｇｔｈ）のように表すことが可能であり、ここで、
アプリケーションは、データの読み取りを要求するが、
バッファを用意しない。従って、バッファは、システム
によって代わりに割り当てられる。同様に、ｆｂｕｆ書
込みインターフェイスは、一般に、ｗｒｉｔ２（ｄｅｓ
ｃｒｉｐｔｏｒ，ｂｕｆ，ｌｅｎｇｔｈ）のように表す
ことが可能であり、ここで、アプリケーションによって
提供されるバッファは、コールが復帰する前に、システ
ムに引き渡される。ｆｂｕｆメカニズムの一例が、１９
９３年の１４ｔｈ ＡＣＭ Ｓｙｍｐｏｓｉｕｍ ｏｎ
Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｐｒｉｎｃｉ
ｐｌｅｓにおける、Ｐｅｔｅｒ Ｄｒｕｓｃｈｅｌ及び
Ｌａｒｒｙ Ｌ．ＰｅｔｅｒｓｏｎによるＦｂｕｆｓ：
Ａ Ｈｉｇｈ−Ｂａｎｄｗｉｄｔｈ Ｃｒｏｓｓ Ｄｏ
ｍａｉｎ Ｔｒａｎｓｆｅｒ Ｆａｃｉｌｉｔｙに示さ
れている。

【０００８】ｆｂｕｆインターフェイスの利点は、文字
ストリーム装置（任意の文字ストリングの入力及び出力
を可能にする装置であり、その例としては、ネットワー
ク・インターフェイス及び直列ライン装置がある）との
読み取りまたは書き込み時に、ゼロ・コピー・データ転
送メカニズムを使用可能にすることである。

【０００９】一方、ｆｂｕｆインターフェイスの重大な
欠点は、ｆｂｕｆインターフェイスは、ディスク・ファ
イルとの読み取りまたは書き込み時に、やはり、コピー
が必要になるということである。このコピー要件は、例
えば、アプリケーションがディスク・ファイルからデー
タを読み取り、読み取ったデータをネットワーク装置に
送る場合に適用される。こうしたアプリケーションを利
用するシステムの一例としてビデオ・サーバがある。高
速バッファを利用して、ファイルからネットワークにデ
ータを転送するには、やはり、カーネル・ファイル・バ
ッファ（または、ディスク・ファイルに対してマッピン
グされたユーザ・バッファ）から高速バッファにデータ
をコピーし、読み取り操作の意味を維持することが必要
になる。従って、先行技術では、ディスクからネットワ
ークへの読み取りの最適化に関連した問題は取り扱って
いない。

【００１０】

【発明が解決しようとする課題】本発明の目的は、アプ
リケーションが、ディスク、テープ、または、ネットワ
ークのような送信側装置のメモリ・オブジェクトから、
ディスク、テープ、または、ネットワークのような受信
側装置へのデータ転送を制御できるようにするための方
法及び装置を提供することにある。

【００１１】

【課題を解決するための手段】アプリケーションは、オ
ペレーティング・システムが高速バッファとデータを記
憶するメモリ・オブジェクトの間にマッピングを実施す
るように要求することが可能である。次に、オペレーテ
ィング・システムは、高速バッファとメモリ・オブジェ
クトの間にマッピングを実施し、これによって、アプリ
ケーションが、メモリ・オブジェクトのデータを受信側
装置に転送するように指示することができる。受信側装
置は、送信側装置に対する直接メモリ・アクセスを利用
して、メモリ・オブジェクトからデータを転送する。さ
らに、アプリケーションが、転送の指示に先立って、メ
モリ・オブジェクトのデータの一部に修正を加えると、
受信側への転送前にデータの修正部分だけがメイン・メ
モリにコピーされる。

【００１２】本書に解説のメカニズムによれば、汎用計
算環境において、メイン・メモリへのコピーをせずに、
送信側から受信側にデータを転送することが可能にな
る。このメカニズムは、汎用オペレーティング・システ
ム内において動作し、異なる装置、ファイル・システ
ム、及び、ユーザ・アプリケーションとうまく相互に機
能する一般的なメカニズムを提供することが可能であ
る。転送は、所定の送信元と宛先にとって、最も効率の
よいシステム部分において実施することが可能である。
例えば、送信側のメモリ・オブジェクトが、ファイルに
相当し、宛先が、ネットワーク・アダプタとディスク・
アダプタの両方が、同じＩ／Ｏバスに結合されたネット
ワークである場合、メモリ帯域幅を消費せずに、ディス
ク・アダプタからネットワーク・アダプタに、直接メモ
リ・アクセス（ＤＭＡ）を直接開始することが可能であ
る。以前は、この操作は、ディスクからカーネルのメイ
ン・メモリへの転送、これに続く、カーネル・メモリか
らユーザ・バッファへの転送、さらに、ユーザ・バッフ
ァからネットワーク装置バッファへのデータ転送、そし
て、最後に、ネットワークへのデータ転送を必要とし
た。

【００１３】

【実施例】以下の説明においては、解説を目的とし、本
発明の完全な理解が得られるように、特定の数、材料、
及び、構成が示される。当該技術の熟練者には明らかな
ように、本発明は、この特定の細部にこだわらずに実施
することが可能である。他の場合には、本発明を不必要
に不明瞭にならないようにするため、周知のシステム
は、線図またはブロック図の形式で示されている。

【００１４】次に、図１を参照すると、本発明の実施例
を利用して、メモリ・オブジェクトとメイン・メモリ内
の高速バッファとの間におけるマッピングを設定するこ
とによって、データ転送を実施するコンピュータ・シス
テムが例示されている。コンピュータ・システム１００
では、プロセッサ１６０によって、メイン・メモリ１１
０に記憶されているオペレーティング・システム命令１
７０及びアプリケーション命令１８０を実行することが
可能である。代替案として、オペレーティング・システ
ム命令１７０は、メイン・メモリ１１０から独立したメ
モリ（不図示）に記憶することも可能である。こうした
場合、独立メモリは、ランダム・アクセス・メモリ（Ｒ
ＡＭ）及び読み取り専用メモリ（ＲＯＭ）のいずれか任
意のほうとすることが可能である。同様に、アプリケー
ション命令１８０も、メイン・メモリ１１０から独立し
たＲＡＭまたはＲＯＭに記憶することが可能である。

【００１５】コンピュータ・システム１００において、
バッファ・マッピング１４０は、送信側装置１２０のメ
モリ・オブジェクト１２５とメイン・メモリ１１０の高
速バッファ１１５の間で設定される。従って、データ転
送１５０は、送信側装置１２０から受信側装置１３０に
直接実施することが可能になる。

【００１６】送信側装置１２０は、マッピングの設定が
可能なメモリ・オブジェクトを備える任意の装置とする
ことが可能である。実施例の１つでは、送信側装置１２
０はディスク・ドライブである。代替案では、送信側装
置１２０はテープ・ドライブである。さらにもう１つの
実施例では、送信側装置１２０は文字ストリーム装置
（例えば、ネットワーク・インターフェイス）である。

【００１７】同様に、受信側装置１３０は、データを送
り届けることが可能な任意の装置とすることが可能であ
る。実施例の１つでは、受信側装置１３０はストリーム
状の装置である（例えば、ネットワーク・インターフェ
イス）。代替案として、受信側装置１３０をディスク・
ドライブまたはテープ・ドライブとすることも可能であ
る。

【００１８】文字ストリーム送信側装置１２０からマッ
ピングを施したファイル受信側装置１３０への転送が実
施される特殊ケースの場合には、マッピングを施したフ
ァイルから高速バッファが生じるので、注意しなければ
ならない。送信側装置１２０と受信側装置１３０の間に
おいて、データ順を維持しなければならない。例えば、
この順序は、送信側、ネットワーク媒体、及び、受信側
でデータ順を維持するネットワーク・プロトコルを用い
ることによって、確保することができる。

【００１９】本発明には、汎用計算環境において、コピ
ーを行わずに、ディスクからネットワークへデータを転
送できるようにするインターフェイスが含まれている。
このインターフェイスは、汎用オペレーティング・シス
テム内において動作し、異なる装置及びユーザ・アプリ
ケーションとうまく相互に機能する一般的なインターフ
ェイスを形成することが可能である。

【００２０】ｒｅａｄであれ、あるいは、ｒｅａｄ２で
あれ、読み取りコールの意味は、バッファにデータを戻
す必要があるということである。ディスクからデータを
読み取って、（通常）そのデータに操作を加えずに、ネ
ットワークに対して送り出そうとする場合、最初にデー
タに対するマッピングを設定すると、より効率のよい転
送メカニズムを得ることができる。この特殊マッピング
は、メモリ・オブジェクト（例えば、ファイル）からマ
ッピングされた（しかし、充填されていない）バッファ
を復帰させる。ｗｒｉｔｅ２操作によって使用される前
に、データが必要になる場合には、アプリケーションが
メモリ・マッピングを施したバッファに接触する際、通
常通りコピーが行われる。しかし、ｗｒｉｔｅ２操作を
利用して、バッファの書込みが行われる場合にはコピー
は行われない。さらに、実際のビットが、ハードウェア
Ｉ／Ｏメモリ階層の最も効率のよい部分を利用して、デ
ィスクからネットワークに転送されるように（例えば、
ある装置から別の装置への直接メモリ・アクセス（ＤＭ
Ａ）のように）、最適化が可能である。

【００２１】ただ単に標準的なマップ・コール（例え
ば、ＵＮＩＸにおけるｍｍａｐコール）を利用するだけ
では、この転送は実施できないという点に留意された
い。これは、標準的なマップ・コールによって、メモリ
・オブジェクトとアプリケーション・バッファの間にマ
ッピングが設定されるためである。しかし、ｗｒｉｔｅ
２コールは、特殊バッファを必要とする。従って、標準
的なマップ・コールは、メモリ・オブジェクトとｗｒｉ
ｔｅ２コールによって必要とされる高速バッファとの間
にマッピングを設定しない。

【００２２】実施例の１つでは、下記のシステム・コー
ルが定義される：mmap2(descriptor,offsett,addr,leng
th,protections,flags)

【００２３】ｍｍａｐ２コールは、そのコールにおいて
指示された保護を利用し、指定されたメモリ・オブジェ
クトの先頭からのオフセットで指定された長さに関し
て、記述子によって表されるメモリ・オブジェクトにマ
ッピングを施す。そのコールは、アドレスａｄｄｒにお
いてマッピングされたバッファを復帰させる。

【００２４】アプリケーションが、メモリ・マッピング
を施されたバッファ（の一部）に接触すると、システム
は、メモリ・オブジェクトから物理的メモリにデータを
コピーする。接触したページだけしかコピーされないと
いう点に留意されたい。

【００２５】図２には、転送前にアプリケーションによ
るデータ修正のため、カーネル・バッファに対するコピ
ーが要求されるデータ転送例が示されている。図２にお
いて、メモリ・オブジェクト１２５の修正を受ける部分
は、高速バッファ１１５に転送される（２４０）。その
後、修正済みのデータ２５０は受信側装置１３０に転送
される。非修正データ２７０は、送信側装置１２０のメ
モリ・オブジェクト１２５から受信側装置１３０に直接
転送することが可能である。

【００２６】ｍｍａｐ２から復帰したバッファは、ｒｅ
ａｄ２から復帰したバッファと同じように取り扱うこと
ができる。従って、このバッファは前述のｗｒｉｔｅ２
コールを利用して書込みが可能である。ｗｒｉｔｅ２に
与えられたバッファと同様、ｗｒｉｔｅ２コールが復帰
すると、そのバッファはシステムに引き渡される。

【００２７】ｗｒｉｔｅ２の実施例の１つに対して、そ
のバッファがｍｍａｐ２コールを利用して得られたもの
か否かを判定するチェックを行う。もしそうであれば、
データは、送信側メモリ・オブジェクトから着信側装置
（ここで、着信側装置は、ｗｒｉｔｅ２コールに指定さ
れた記述子によって表示される）に転送される。

【００２８】特定の送信側及び着信側が指示されると、
この転送は、ハードウェア・メモリ・システム／バスの
最も効率のよい部分において実施される。従って、例え
ば、送信側メモリ・オブジェクトがファイルに相当し、
着信側がネットワークであって、かつネットワーク・ア
ダプタとディスク・アダプタが両方とも同じＩ／Ｏバス
で接続される場合、メモリ帯域幅を消費せずに、ディス
ク・アダプタからネットワーク・アダプタへの直接メモ
リ・アクセス（ＤＭＡ）を開始することが可能である。
この機能は、より高度なハードウェア編成において活用
することが可能である。以前は、ディスクからメイン・
メモリへの転送と、これに続く、メイン・メモリからネ
ットワークへの転送とが必要とされた。

【００２９】代替実施例に関して、ｍａｐｐｉｎｇ＿ｔ
ｏ＿ｂｕｆ操作が定義される。この実施例の場合、ｍａ
ｐｐｉｎｇ＿ｔｏ＿ｂｕｆコールが、通常のシステムｍ
ｍａｐコールによって復帰したメモリ・マッピングを施
した領域に適用される。こうした操作は、一般に有効で
はあるが、バッファを得るのに２つのコールが必要にな
るので（単一のｍｍａｐ２コールの代わりに、ｍｍａｐ
コールにｍａｐｐｉｎｇ＿ｔｏ＿ｂｕｆコールが後続す
る）、この代替実施例は、前述の実施例に比べてコスト
がかかる。さらに、単一ｍｍａｐ２コールが利用される
と、そのコールによって伝達される意味情報がバッファ
を得るマッピングの最適化の実現を可能にするが、２つ
のコールを利用すると、この情報の伝達が第２のコール
まで遅れることになる。

【００３０】従って、本書に提示のメカニズムによれ
ば、ディスクからネットワークへの、ゼロ・コピーの効
率のよいデータ転送を実施し、同時に、汎用オペレーテ
ィング・システムのフレキシビリティを保持することが
可能になる。用いられる全てのコールは、Ｉ／Ｏシステ
ムの他の部分に適用可能であり、任意のユーザ・アプリ
ケーションによって利用可能である。この解決策は、カ
ーネルに限定されるものではなく、特殊化アプリケーシ
ョンまたは装置に限定されるものでもない。

【００３１】ディスクとネットワークの間における転送
は、コンピュータ・システムの最も効率のよい部分を利
用して、実施することが可能である。これは、ｍｍａｐ
２にｗｒｉｔｅ２が後続する組み合わせによって、２つ
のこと、すなわち、ファイルに対する高速バッファのマ
ッピング、及び、これに続くコピーを必要としない書込
みが可能になる。従って、最も適切な瞬間まで、送信側
ディスクから着信側ネットワークへのデータ転送が行わ
れる時点を遅延させることが可能である。

【００３２】転送メカニズムは、特定のオペレーティン
グ・システムから独立しているが、下記の実施例では、
アプリケーション・プログラムとＵＮＩＸカーネルの間
におけるバッファ管理及び交換に関する効率のよいゼロ
・コピー・フレームワークが解説される。基礎となるバ
ッファ管理フレームワーク、及び、それと高速ネットワ
ーク化ソフトウェアの統合に関する論述と共に、アプリ
ケーション・プログラミング・インターフェイスが提示
される。提示の仮想高速バッファ・メカニズムは、ファ
イル・システムとネットワークＩ／Ｏの組み合わせを取
り扱うため、ネットワークのスループットを気にせずに
動作する。フレームワークは、Ｓｏｌａｒｉｓのよう
な、汎用の、市販されている、ＵＮＩＸベースのオペレ
ーティング・システムによって実施することにより、典
型的なＵＮＩＸ Ｉ／Ｏ動作（例えば、レイヤ処理、チ
ェック・サムの計算、データ移動）のデータ接触オーバ
ヘッドを減少させることが可能である。この改良は、ネ
ットワーク化／分散マルチメディア・システムのよう
に、超高速の大量データ転送を必要とするアプリケーシ
ョンにおいて極めて明らかになる。

【００３３】名前仮想高速バッファ（ｖｉｒｔｕａｌ
ｆｂｕｆ）を利用して、本書に解説の転送メカニズムと
伝統的な高速バッファ・メカニズムが区別される。新し
いアプリケーション・プログラミング・インターフェイ
スについては、基礎となるバッファ管理フレームワー
ク、及び、それとＵＮＩＸによるネットワーク化の実施
との統合と共に論じられる。さらに、基本ｆｂｕｆメカ
ニズムが、ファイル（ディスク）Ｉ／Ｏを含むように拡
張される。

【００３４】伝統的なＵＮＩＸ ｒｅａｄ／ｗｒｉｔｅ
システム・コールの意味は、暗黙的に、バッファの転送
ではなく、データ・コピーを必要とするということであ
る。伝統的なＵＮＩＸ ｒｅａｄインターフェイスの構
文では、アプリケーション・プログラムがバッファのア
ドレスを供給する必要があるので、カーネルからアプリ
ケーションへのバッファの転送にとって不十分である。
仮想ｆｂｕｆメカニズムは、これらの欠点を取り扱う新
しいアプリケーション・プログラミング・インターフェ
イスを定義することによって、その概念をＵＮＩＸ環境
に適応させる。

【００３５】仮想ｆｂｕｆの以下の特性に留意された
い。各仮想ｆｂｕｆは、アプリケーション・プログラム
またはカーネルによって所有されるか、または、仮想ｆ
ｂｕｆバッファ・プール内に含まれる。出力時に、仮想
ｆｂｕｆ（任意のバッファではなく）をカーネルに送る
ことによって、アプリケーションは、伝統的な書込みシ
ステム・コールの定義に潜在するデータ・コピー・オー
バヘッドの節約が保証される。

【００３６】同様に、入力時に、カーネルから仮想ｆｂ
ｕｆ（任意のバッファではなく）にデータを受信するこ
とによって、アプリケーションは、伝統的な読み取りシ
ステム・コールのデータ・コピー・オーバヘッドの節約
が保証される。

【００３７】Ｉ／Ｏサブシステム（装置ドライバ、ＳＴ
ＲＥＡＭＳモジュール／ドライバ（１９９０年の、ＡＴ
＆Ｔによる、「ＡＴ＆Ｔ Ｓｔｒｅａｍｓ Ｒｅｆｅｒ
ｅｎｃｅ」参照のこと）、ファイル・システム ）は、
仮想ｆｂｕｆを割り当てることが可能である。最適な利
用に関して、Ｉ／Ｏサブシステムは、ディスクまたはテ
ープＩ／Ｏの場合のように、入力を開始する前に、ある
いは、ネットワークまたは直列ラインＩ／Ｏの場合のよ
うに、受信したデータのある部分を調べることによっ
て、利用するのに適したバッファ・プールを判定するこ
とができる。

【００３８】各種装置ドライバのカーネル・アドレスと
Ｉ／Ｏアドレス間における翻訳のキャッシングは、各ア
プリケーション・アドレス空間における任意のバッファ
と比較すると、小さいプール・サイズと、結果生じるｆ
ｂｕｆの再使用によって容易である。こうしたキャッシ
ングによって、オーバヘッドがさらに節約される。

【００３９】仮想ｆｂｕｆメカニズムによれば、メモリ
参照を利用する代わりに、高速バッファを５つの組＜コ
ンテキスト、ユーザ・アドレス、装置、オフセット、長
さ＞として実施することによって、ｆｂｕｆの概念が強
化される。必ずしも、バッファが割り当てられる場合で
もなく、あるいは、バッファが、アドレス空間（ドメイ
ン）間で受け渡される場合でもなく、内容がアクセスさ
れた場合に限って、バッファの内容を保持するためのメ
モリが割り当てられる。この区別によって、その表現を
Ｉ／Ｏの遅延評価の基礎とすることが可能になるので、
ｆｂｕｆフレームワークにより大きいパワーとフレキシ
ビリティが与えられることになる。一例として、Ｉ／Ｏ
装置間における動的結合を構築する可能性がある。こう
したシナリオによれば、これらのバッファを高性能ハー
ドウェア構成に関連して利用することによって、ＵＮＩ
Ｘファイル・システムを介したアプリケーション制御に
よる装置間データ転送が可能になる。

【００４０】もとのｆｂｕｆの概念は、＜コンテキス
ト、ユーザ・アドレス、装置、オフセット、長さ＞とい
う５組のｆｂｕｆ表現を利用して、ＵＮＩＸファイルに
マッピングされるアプリケーション・アドレス空間の部
分から仮想ｆｂｕｆを自動的に生成するインターフェイ
スを設けることによって、メモリ・マッピングを施した
ファイルに拡張される。

【００４１】仮想ｆｂｕｆアプリケーション・プログラ
ミング・インターフェイスは、ファイル（装置）記述子
から読み取られるデータ、及び、ファイル（装置）記述
子に書き込まれるデータをバッファに割り当てるため、
システム・コール及びライブラリ・ルーチンを可能にす
る。下記のインターフェイスは、標準的なＡＮＳＩＣ言
語構文を利用して定義されている。ｖｆ＿ｒｅａｄ、ｖ
ｆ＿ｗｒｉｔｅ、及び、ｖｆ＿ｍａｐは、それぞれ、ｒ
ｅａｄ２、ｗｒｉｔｅ２、及びｍｍａｐ２に対応する。

【００４２】 ssize_t vf_read (int fd,void ^**bufpp,size_t nbytes) ssize_t vf_write (int fd,const void ^*bufp,size_t nbytes) caddr_t vf_mmap (caddr_t addr,size_t len,int prot,int flags, int filedes,off_t off) void ^*vf_allocate (size_t size) void ^*vf_deallocate (voidptr,size_t size)

【００４３】データを読み取り、そのデータを処理する
か、または、廃棄するアプリケーションは、ｖｆ＿ｒｅ
ａｄインターフェイスを利用することができる。データ
を読み取り、オプションでそのデータにフィルタリング
を施し、その（フィルタリングを施された）データを書
き込むアプリケーションは、ｖｆ＿ｒｅａｄインターフ
ェイスを利用するか、あるいは、ｖｆ＿ｗｒｉｔｅイン
ターフェイスが後続するｖｆ＿ｍｍａｐインターフェイ
スを利用することが可能である。データを発生し、次
に、その発生したデータを書き込むアプリケーション
は、ｖｆ＿ｗｒｉｔｅインターフェイス及びｖｆ＿ｄｅ
ａｌｌｏｃａｔｅインターフェイスが後続するｖｆ＿ａ
ｌｌｏｃａｔｅインターフェイスを利用することが可能
である。

【００４４】ｖｆ＿ｒｅａｄインターフェイスは、やは
り、カーネルによって割り当てられるアドレス ^*ｂｕｆ
ｐｐにカーネルによって割り当てられる新しいバッファ
へデータを読み取る点を除けば、標準的なＵＮＩＸ ｒ
ｅａｄインターフェイスと同様である。

【００４５】ｖｆ＿ｗｒｉｔｅインターフェイスは、下
記の顕著な点を除けば、標準的なＵＮＩＸ ｗｒｉｔｅ
インターフェイスと同様である。

【００４６】１．アドレスｂｕｆｐのバッファは、コー
ルが復帰するとオペレーティング・システムに転送され
る。アプリケーションの観点からすると、コールが復帰
すると、あたかも暗黙的ｖｆ＿ｄｅａｌｌｏｃａｔｅが
生じるかのように見える。コールの復帰後、バッファ ^*
ｂｕｆｐにアクセスし、あるいは、これを修正しようと
する試みの結果は、不明確である。

【００４７】２．アドレスｂｕｆｐのバッファは、 （ａ）ｂｕｆｐ＝ｖｆ＿ａｌｌｏｃａｔｅ（ｓｉｚｅ） に対するコールによって明示的にあるいは、 （ｂ）ｓｉｚｅ＝ｖｆ＿ｒｅａｄ（ｆｄ，＆ｂｕｆｐ，
ｎｂｙｔｅｓ） をコールすることによって暗黙的に、あるいは、 （ｃ）ｂｕｆｐ＝ｖｆ＿ｍｍａｐ（ａｄｄｒ，ｌｅｎ，
ｐｒｏｔ，ｆｌａｇｓ，ｆｉｌｅｄｅｓ，ｏｆｆ）＋ｏ
ｆｆｓｅｔ （ここで、ｏｆｆｓｅｔは、ｌｅｎ未満）のｖｆ＿ｍｍ
ａｐコールを利用して、他の何らかのファイルｆｉｌｅ
ｄｅｓにマッピングされたユーザ・アドレス空間の範囲
内において、バッファを参照することによって、割り当
てられなければならなかった。

【００４８】ｖｆ＿ｍｍａｐインターフェイスは標準的
なＵＮＩＸ ｍｍａｐと似ている。ただし、それには、
ファイルにマッピングされたユーザ・アドレス範囲のど
の部分でも、ｖｆ＿ｗｒｉｔｅコールにおいて利用可能
であり、仮想ｆｂｕｆとして取り扱われるという追加特
性が備わっている。ｖｆ＿ａｌｌｏｃａｔｅインターフ
ェイスは仮想ｆｂｕｆアロケータである。ｖｆ＿ｄｅａ
ｌｌｏｃａｔｅインターフェイスはｖｆ＿ａｌｌｏｃａ
ｔｅの相補機能である。これは、仮想ｆｂｕｆ割り当て
解除する。

【００４９】バッファ割り当てメカニズムｖｆ＿ａｌｌ
ｏｃａｔｅは、プロセス仮想アドレス空間に十分な空間
が存在する場合でも、エラー・コードＥＮＯＭＥＭのた
めに失敗する可能性がある。アプリケーションは、成功
する（または、異なる理由で失敗する）まで、失敗した
コールを再試行することで、こうした失敗に対処するよ
うに書くことが可能である。代替案として、失敗が生じ
ると、標準的なｒｅａｄ／ｗｒｉｔｅインターフェイス
に戻り、これによって、失敗の取り扱いをアプリケーシ
ョン・ライタにとって透過性にするライブラリに、上述
のコールを封じ込めることも可能である。

【００５０】また、仮想ｆｂｕｆメカニズムによって、
Ｉ／Ｏサブシステムが仮想ｆｂｕｆの割り当て及び解除
を行うための、下記のカーネル・フックも得られる。

【００５１】 void ^*vf_pid2handle (pid_t pid,caddr_t) mblk_t ^*vf_allocb (void*handle,int size)

【００５２】ｖｆ＿ｐｉｄ２ｈａｎｄｌｅインターフェ
イスは、ｐｉｄパラメータによって識別されるプロセス
の代わりに、Ｉ／ＯのためのＩ／Ｏサブシステムによる
仮想ｆｖｕｆ割り当てに用いられる不透過性ハンドルを
復帰させる。仮想ｆｂｕｆバッファ・プールがｐｉｄに
よって識別されるプロセスのために存在しない場合に
は、ＮＵＬＬ値のハンドルを復帰させる。

【００５３】ｖｆ＿ａｌｌｏｃｂインターフェイスは、
ｍｂｌｋ＿ｔに基づく仮想ｆｂｕｆにポインタを割り当
てかつ戻す。このインターフェイスは、どの仮想ｆｂｕ
ｆバッファ・プールから、ｍｂｌｋ＿ｔを割り当てるべ
きかを指定するハンドル・パラメータを除けば、ＳＴＲ
ＥＡＭＳ ｒｏｕｔｉｎｅ ａｌｌｏｃｂに似ている。
仮想ｆｂｕｆバッファ・プールからｍｂｌｋ＿ｔを割り
当てることができない場合、ｍｂｌｋ＿ｔの割り当ては
ａｌｌｏｃｂを利用して行われる。ＮＵＬＬの復帰は、
ｍｂｌｋ＿ｔを割り当てることができないということを
表している。仮想ｆｂｕｆをベースにしたｍｂｌｋ＿ｔ
は、割り当て解除するか、あるいは、ＳＴＲＥＡＭＳ
ｒｏｕｔｉｎｅ ｆｒｅｅｂを利用して、バッファ・プ
ールに戻すことが可能である。

【００５４】この実施は、論理的に、バッファ・プール
・マネージャ（図３）及びシステム・コール・コンポー
ネント（図４）に分割される。

【００５５】図３には、転送メカニズムの実施例の１つ
に関するバッファ・プール・マネージャが示されてい
る。仮想ｆｂｕｆバッファを利用する各アプリケーショ
ン・プログラムは、バッファ・プール・マネージャ３１
０の異なる例に関連している。バッファ・マネージャ３
１０は、メモリの割り当て、独立した各仮想ｆｂｕｆの
割り当て／割り当て解除の追跡、ユーザ・アドレスとカ
ーネル・アドレスの間におけるマッピングの管理、及
び、ｆｂｕｆと既存のＩ／Ｏフレームワークの間におい
て変換を行うためのメカニズム（例えば、ＳＴＲＥＡＭ
Ｓフレームワークによって利用されるｍｂｌｋ）の提供
に責任を負う。これらの機能は、それぞれ、メモリ・ア
ロケータ３２０、トラッカ３３０、アドレス・トランス
レータ３４０、及び、バッファ・コンバータ３５０によ
って実施される。

【００５６】各バッファ・プールは、いくつかのセグメ
ントから構成される。セグメントは、標準的なｍｍａｐ
インターフェイスを支援することが可能なファイル・シ
ステム・オブジェクト３６０によってバック・アップさ
れる、連続した範囲のユーザ・アドレスを表している。
バッファ・プール・マネージャ３１０は、それ自体、こ
うしたファイル・システム・オブジェクトの特殊例であ
り、匿名のメモリの供給者である。物理的メモリの割り
当ては、可能性のある最遅の瞬間まで、すなわち、アプ
リケーション・プログラムが、ｆｂｕｆにアクセスする
（ページ・フォールトを生じさせる）か、あるいは、ア
プリケーションが、ｆｂｕｆをカーネルに転送するか、
あるいは、Ｉ／Ｏサブシステムが、プールからｆｂｕｆ
を割り当てるまで、据え置かれる。この割り当ては、ブ
ロック単位で実施され、ブロック・サイズは、同調可能
なパラメータである。

【００５７】カーネル及びアプリケーション・プログラ
ムからのｆｂｕｆの同時割り当て及び割り当て解除が支
援される。これを可能にするため、バッファ・マネージ
ャ３１０のトラッカ３３０は、カーネル・アロケータ／
デアロケータ・コンポーネント３３３と、ユーザ・ライ
ブラリ・アロケータ／デアロケータ・コンポーネント３
３７を備えている。両方のドメインにおいて、アロケー
タ／デアロケータ・コンポーネント３３３は、フリーな
ｆｂｕｆのリスト３７０にアクセスし、操作を加える。
フリー・リスト３７０は、これによって、一貫した状態
に保たれ、操作は、２つのドメインに対して自動に保た
れる。

【００５８】実施例の１つでは、フリー・リスト３７０
は、１がフリー・ページを表し、０が割り当て済みのペ
ージを表す、ビット・ストリングとして実施される。そ
のストリングは、それぞれ、ページ・ビットを含んでい
るワード単位でアクセスされる（アーキテクチャのネイ
ティブ・ワード・サイズを利用して）。スピン・ロック
によって、同時アクセスを管理するため、各ワードへの
アクセスが保護される。各ワード毎のロックは、少数の
命令（割り当て要求を満たすか、あるいは、ページがフ
リーであることを表すビットをセットするのに十分なフ
リー・ページが存在することを判定するのに十分な）に
関して保持されるだけであり、従って、ロックが保持さ
れている間に、スピニングが実施される。

【００５９】この実施例に関して、ロックを保持してい
る間、アプリケーション・プログラムを優先使用するこ
とによって、潜在的な性能問題を生じることになる可能
性がある点に留意されたい。従って、ビットマップ・ス
トリングに対する同調可能な数の反復が済むと、カーネ
ル割り当ては失敗する。同様に、カーネル・デアロケー
タは、同調可能な数の反復内において、適合するロック
を獲得するのに失敗し、それより後の時点において割り
当て解除を実施しようとする場合、内部待ち行列におい
て割り当て解除を待機させる。

【００６０】一般的なケースでは、バッファのユーザ・
アドレス及びカーネル・アドレスは異なることになる。
バッファ・マネージャのアドレス・トランスレータ３４
０は、マッピングを維持し、１つのマッピングをもう１
つのマッピングから決定することができるようにする。

【００６１】アドレス翻訳以外に、バッファ・マネージ
ャ３１０は、ｆｂｕｆと既存のＩ／Ｏフレームワークの
バッファの間で変換を行うメカニズム３５０（例えば、
ＳＴＲＥＡＭＳフレームワークによって利用されるｍｂ
ｌｋ）も提供する。この変換機能によって、各ｆｂｕｆ
と、既存のＩ／Ｏドライバ、ネットワーク・プロトコル
・スタック等との統合が容易になる。

【００６２】バッファ・マネージャ３１０は、動的にロ
ードされた装置ドライバとして実施される。システム・
コール・コンポーネントは動的にロードされる。Ｓｏｌ
ａｒｉｓシステムにｆｂｕｆ能力を付与するのに必要な
ものは、これら２つのコンポーネントだけである。図４
には、転送メカニズムの実施例の１つに関するシステム
・コール・コンポーネント４００内におけるマッピング
・インターフェイス４１０、読み取りインターフェイス
４２０、及び、書き込みインターフェイス４３０が示さ
れている。

【００６３】実施のシステム・コールには、いくつかの
制限があるので、コールの復帰後、アプリケーションに
よってバッファに修正を加えなければならない。一般
に、Ｉ／Ｏサブシステム及びオペレーティング・システ
ムは、この規律を強制しない。バッファに対する制限条
件が満たされない場合、ｖｆ＿ｗｒｉｔｅの実施は、ｖ
ｆ＿ｄｅａｌｌｏｃａｔｅが後続する標準的なｗｒｉｔ
ｅコールに変わる。

【００６４】実施例の１つでは、共用が、個々のアプリ
ケーションとカーネルの間だけにおいて生じ、任意のア
プリケーション間では生じないことを保証するため、仮
想ｆｂｕｆプールは、プロセスｉｄによって区分化され
る。

【００６５】現在のところ望ましい実施例及び代替実施
例に関連して、本発明の方法及び装置について解説して
きたが、当該技術の熟練者には明らかなように、本発明
は、付属の請求項の精神及び範囲内において、修正及び
変更を加えて実施することが可能である。従って、明細
書及び図面は、制限を意味するものではなく、例示を意
味するものであるとみなすべきである。

【図面の簡単な説明】

【図１】 本発明の実施例を利用し、メイン・メモリ内
のメモリ・オブジェクトと高速バッファの間にマッピン
グを設定することによって、データ転送を実施するコン
ピュータ・システムを示す図である。

【図２】 転送前におけるアプリケーションによるデー
タ修正のために、カーネル・バッファへのコピーが必要
になるデータ転送例を示す図である。

【図３】 転送メカニズムの実施例の１つに関するバッ
ファ・プール・マネージャを示す図である。

【図４】 転送メカニズムの実施例の１つに関するシス
テム・コール・コンポーネント内のマッピングインター
フェイス、読み取りインターフェイス、及び、書き込み
インターフェイスを示す図である。

【符号の説明】

１００ コンピュータ・システム １１０ メイン・メモリ １１５ 高速バッファ １２０ 送信側装置 １２５ メモリ・オブジェクト １３０ 受信側装置 １４０ バッファ・マッピング １５０ データ転送 １６０ プロセッサ １７０ オペレーティング・システム命令 １８０ アプリケーション命令 ３１０ バッファ・プール・マネージャ ３２０ メモリ・アロケータ ３３０ トラッカ ３４０ アドレス・トランスレータ ３５０ バッファ・コンバータ ３７０ フリー・リスト ４００ システム・コール・コンポーネント ４１０ マッピング・インターフェイス ４２０ 読み取りインターフェイス ４３０ 書き込みインターフェイス

───────────────────────────────────────────────────── フロントページの続き (72)発明者 モチ・エヌ・サーデニ アメリカ合衆国 95054・カリフォルニア 州・サンタ クララ・ビスタ クラブ サ ークル・ナンバ203・1540

Claims (11)

【特許請求の範囲】
1. 【請求項１】 （Ａ）オペレーティング・システムが、
   高速バッファと、送信側装置のデータを記憶しているメ
   モリ・オブジェクトとの間のマッピングを設定すること
   をアプリケーションが要求するステップと、 （Ｂ）オペレーティング・システムが、高速バッファと
   メモリ・オブジェクトの間のマッピングを実行するステ
   ップと、 （Ｃ）アプリケーションが、高速バッファにマッピング
   されたメモリ・オブジェクトのデータを受信側装置に転
   送するように指示するステップとから構成されるデータ
   転送を制御する方法。
2. 【請求項２】 さらに、受信側装置が、送信側装置に対
   する直接メモリ・アクセスを利用して、メモリ・オブジ
   ェクトからデータを転送するステップが含まれることを
   特徴とする請求項１に記載の方法。
3. 【請求項３】 アプリケーションが、メモリ・オブジェ
   クトのデータにステップ（Ｃ）の前に修正を加える場
   合、受信側装置に対する転送に先立って、メイン・メモ
   リにデータをコピーするステップが含まれることを特徴
   とする請求項１に記載の方法。
4. 【請求項４】 アプリケーションが、メモリ・オブジェ
   クトのデータにステップ（Ｃ）の前に修正を加える場
   合、受信側装置に対する転送に先立って、メイン・メモ
   リにデータの修正部分だけをコピーするステップが含ま
   れることを特徴とする請求項１に記載の方法。
5. 【請求項５】 高速バッファと、送信側装置のデータを
   記憶しているメモリ・オブジェクトとの間のマッピング
   をオペレーティング・システムが行うことをアプリケー
   ションに要求させるマッピング要求手段と、 オペレーティング・システムが、メモリ・オブジェクト
   と高速バッファの間におけるマッピングを実行するマッ
   ピング手段と、 高速バッファにマッピングされたメモリ・オブジェクト
   のデータを受信側装置に転送するようにアプリケーショ
   ンに指示させる書込み手段とから構成されるデータ転送
   を制御する装置。
6. 【請求項６】 さらに、受信側装置が、送信側装置に対
   する直接メモリ・アクセスを利用して、メモリ・オブジ
   ェクトからのデータ転送を行える直接メモリ・アクセス
   手段が含まれていることを特徴とする請求項５に記載の
   装置。
7. 【請求項７】 さらに、アプリケーションが、メモリ・
   オブジェクトのデータを受信側装置に転送するように指
   示する前に、メモリ・オブジェクトのデータに修正を加
   えると、これを検出し、また、アプリケーションがデー
   タに修正を加えると、受信側装置に転送する前に、メイ
   ン・メモリにデータをコピーするコピー手段が含まれて
   いることを特徴とする請求項５に記載の装置。
8. 【請求項８】 さらに、アプリケーションが、メモリ・
   オブジェクトのデータを受信側装置に転送するように指
   示する前に、メモリ・オブジェクトのデータの一部に修
   正を加えると、これを検出し、また、アプリケーション
   がデータに修正を加えると、受信側装置に転送する前
   に、メイン・メモリにデータの修正部分だけをコピーす
   るために用いられるコピー手段が含まれていることを特
   徴とする請求項５に記載の装置。
9. 【請求項９】 システム・コール・コンポーネントが、
   高速バッファが送信側装置のデータを記憶しているメモ
   リオブジェクトにマッピングされるようにアプリケーシ
   ョンに指定させ、また、メモリのデータが受信側装置に
   転送されるようにアプリケーションに指定させるステッ
   プと、 バッファ・プール・マネージャが、システム・コール・
   コンポーネントの指令を受けて、高速バッファに対する
   メモリ・オブジェクトのマッピングを実施するステップ
   から構成される、 データ転送を制御するための装置を設ける方法。
10. 【請求項１０】 メイン・メモリにアプリケーション及
    びオペレーティング・システム命令が記憶されているコ
    ンピュータ・システムで、データを記憶しているメモリ
    ・オブジェクトを備えた送信側装置から受信側装置への
    データ転送を制御する方法において、 高速バッファとメモリ・オブジェクトとの間のマッピン
    グをオペレーティング・システムによって実施すること
    をアプリケーションが要求するステップと、 オペレーティング・システムが、高速バッファとメモリ
    ・オブジェクトとの間のマッピングを実施するステップ
    と、 アプリケーションが、高速バッファに対してマッピング
    されたメモリ・オブジェクトのデータを受信側装置に転
    送するように指示するステップとから構成される方法。
11. 【請求項１１】 メイン・メモリにアプリケーション及
    びオペレーティング・システム命令が記憶されているコ
    ンピュータ・システムにおける、データを記憶している
    メモリ・オブジェクトを備えた送信側装置から受信側装
    置へのデータ転送を制御するための装置において、 オペレーティング・システムが高速バッファとメモリ・
    オブジェクトとの間のマッピングを実施することをアプ
    リケーションに要求させるマッピング要求手段と、 オペレーティング・システムに高速バッファとメモリ・
    オブジェクトとの間のマッピングを実施させるマッピン
    グ手段と、 高速バッファに対してマッピングされたメモリ・オブジ
    ェクトのデータを受信側装置に転送するようにアプリケ
    ーションに指示する書込み手段とから構成される装置。