(57)【要約】【課題】無駄なデータコピーを最小限にし、また物理メモリの使用量も削減する事を目的とする。【解決手段】デマンドページング処理をする情報処理装置が、ユーザプログラムにより要求されたデータのサイズの領域をユーザ空間に確保する手段と、前記ユーザプログラムにより要求されたデータがカーネル空間に割り付けられた物理メモリに読み込まれると、読み込まれたサイズを前記ユーザプログラムに返却する手段と、前記データが読み込まれた後に、前記ユーザプログラムによる前記データに対するページフォルトが検出されると、前記物理メモリを前記ユーザ空間の前記領域に割り付ける手段と、有することによって課題を解決する。【選択図】図１
2011118625.tif 000002
【特許請求の範囲】
【請求項１】
デマンドページング処理をする情報処理装置であって、
ユーザプログラムにより要求されたデータのサイズの領域をユーザ空間に確保する手段と、
前記ユーザプログラムにより要求されたデータがカーネル空間に割り付けられた物理メモリに読み込まれると、読み込まれたサイズを前記ユーザプログラムに返却する手段と、
前記データが読み込まれた後に、前記ユーザプログラムによる前記データに対するページフォルトが検出されると、前記物理メモリを前記ユーザ空間の前記領域に割り付ける手段と、
を有することを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に関する。
【背景技術】
【０００２】
ＵＮＩＸ（登録商標）系のオペレーティングシステムを例にあげると、ユーザ空間とカーネル（デバイスドライバも含む。）空間は、完全に分離されている。ユーザ空間からデバイスにアクセスしたり、ユーザ空間のバッファ（ユーザ空間に割り付けられた物理メモリ）に対してデバイスからのデータを直接格納したりすることができない。これは、カーネル空間の保護やセキュリティ面からそうなっていることに加え、多くの場合、デバイスとのデータ入出力時に物理的に連続したメモリ空間が要求されることによる。なお、ユーザ空間のバッファは、ＭＭＵ（メモリ管理ユニット）等によりページ単位に物理メモリ空間（物理メモリ）からバラバラに割当てられる。つまり、連続していないので使用できない。
この制限は、一部のリアルタイムＯＳ（全てをカーネルモードで動かすＯＳ）には無いメモリ保護やシステム保護を提供する反面、即時性を要求されるデータの入出力に関しては性能的に劣る原因となっている。
このＵＮＩＸのような保護されたメモリ空間を持つＯＳの場合、従来はデバイスからデータを読み出すとき、リード（read）システムコールによってユーザ空間のバッファが渡される。デバイスドライバ内のローカルのバッファにデバイスからデータが読み出された後、ユーザ空間のバッファにコピー処理が行われていた。そして、この場合の処理の流れは、以下のようになっている。
ユーザプログラム（ユーザアプリケーション）は、リードバッファを確保し、リードシステムコールを発行して、デバイスドライバにリードバッファのアドレス、リードサイズを渡し、データリードを依頼する。デバイスドライバは、自身のローカルのバッファ（物理メモリかつ連続しているバッファ）を確保し、このバッファにデバイスから読み出したデータを格納する。デバイスドライバは、ユーザプログラムにより渡されたユーザ空間のバッファに対して、自身のローカルのバッファから要求されたサイズのコピーを行う。そして、デバイスドライバは、ユーザプログラムにリードできたサイズを返却し、リードシステムコールを終了する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−３２１４０７号公報
【特許文献２】特開２００５−３０１６７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
前述のような従来の手法の場合、以下に示す問題がある。例えば、ユーザ空間のバッファとデバイスドライバのバッファとを用意する必要があるため、物理メモリの使用量が増加する。また、例えば、デバイスから取得したデータ全体のコピー処理が発生するために、スループットが低下する。また、例えば、ユーザプログラムは、読み出したデータ全体を使用するとは限らず、一部のデータしか結果的に使用しなかった場合、割当てた物理メモリと物理メモリの割当処理の時間とに無駄が発生する。つまり、ＵＮＩＸのような保護されたメモリ空間を管理するＯＳ上でデバイスからデータをリードする場合、メモリ空間の保護やセキュリティを確保することができる反面、リアルタイムＯＳと比較して物理メモリの使用量や、スループットが大きくなる問題がある。
【０００５】
本発明はこのような問題点に鑑みなされたもので、ＵＮＩＸのようなオペレーティングシステムを活用した場合でも、物理メモリをより効率よく利用することを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明に係る情報処理装置は、デマンドページング処理をする情報処理装置であって、ユーザプログラムにより要求されたデータのサイズの領域をユーザ空間に確保する手段と、前記ユーザプログラムにより要求されたデータがカーネル空間に割り付けられた物理メモリに読み込まれると、読み込まれたサイズを前記ユーザプログラムに返却する手段と、前記データが読み込まれた後に、前記ユーザプログラムによる前記データに対するページフォルトが検出されると、前記物理メモリを前記ユーザ空間の前記領域に割り付ける手段と、を有することを特徴とする。
【発明の効果】
【０００７】
本発明によれば、ＵＮＩＸのようなオペレーティングシステムを活用した場合でも、物理メモリをより効率よく利用できる。
【図面の簡単な説明】
【０００８】
【図１】情報処理装置の構成を示す図である。
【図２】ページテーブルの例を示す図である。
【図３】プロセス仮想空間を管理するための管理情報の例を示す図である。
【図４】デマンドページングバッファ獲得処理に係るフローチャートを示す図である。
【図５】デバイスドライバリード処理に係るフローチャートを示す図である。
【図６】リードバッファデマンドページング処理に係るフローチャートを示す図である。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面に基づいて説明する。
【００１０】
図１は、本実施形態に係る情報処理装置の構成を示す図である。
１１は、ＣＰＵであり、本情報処理装置のほぼ全てを管理している。１２は、ＣＰＵ１１に内蔵（ハードウエアによってはＣＰＵ１１外にある。）されているメモリ管理ユニット（ＭＭＵ）であり、後述のメモリ１３を仮想アドレス空間（仮想空間）に割当てる機能や、ページフォルトを検出する機能を有する。１３は、メモリ（メインメモリ）であり、ＣＰＵ１１から必要に応じて読み書きされる。１４は、外部デバイスであり、ユーザプログラムの要求や、オペレーティングシステムの必要に応じてデバイスドライバを介して読み書きされる。
【００１１】
図２は、オペレーティングシステム（以降ＯＳと表記する。）とＭＭＵ１２とによって管理される、仮想空間と物理メモリとの関係を表した図である。なお、本実施形態では、次のような仮想空間の管理を行うＭＭＵを前提に説明する。
・  ３２ビットの仮想／物理アドレス空間
・  １ページ４ＫＢ
・  １段階のページテーブル変換機構
・  ページフォルトの検出は、ページテーブル２３の要素の下位１２ビット（属性ビット）の設定によって行われる。属性ビットには、リードオンリ（FLAG_RONLY）、ライトオンリ（FLAG_WONLY）、リードライト可能（FLAG_RW）、実行可能（FLAG_EXEC）、割当て無し（FLAG_NULL）が設定される。
【００１２】
プロセス仮想空間２１は、ユーザプログラムが有することができる仮想空間を表している。この仮想空間は、0x00000000〜0xffffffffの３２ビットアドレス空間を取ることができる。
仮想アドレス２２は、プロセス仮想空間２１内のあるアドレスを示している。仮想アドレス２２は、下位１２ビットと上位２０ビットとに分けることができる。下位１２ビットは、ＭＭＵ１２によって変換される物理アドレスにより指定される物理ページ内のオフセットを表す。１ページが４ＫＢであるので、そのサイズが１２ビットとなっている。上位２０ビットは、後述するページテーブル２３のエントリを表す。これは２０ビットあるので、1048576エントリをインデックスする。１つのインデックスで４ＫＢをマップするので、ページテーブル２３全体では、1048578*4096=0x100000000である。
【００１３】
ページテーブル２３は、ＭＭＵ１２が仮想空間（例えば、プロセス仮想空間２１）と物理空間（例えば、後述の物理アドレス空間２５）とを変換するためのテーブルである。上述したように、ページテーブル２３のエントリは、1048576であり、１つのエントリで１ページ（４ＫＢ）をマップする。ページテーブルエントリ２４は、ページテーブル２３内の１つの要素である。この要素（ページテーブルエントリ２４）は、下位１２ビットと、上位２０ビットに分かれている。下位１２ビットは、属性ビットである。属性ビットには、リードオンリ、ライトオンリ、リードライト可能、実行可能、割当て無しのビットが設定されるものとする。上位２０ビットは、物理アドレス空間２５を４ＫＢごとに分けた物理ページの１つを表す。
物理アドレス空間２５は、メモリ１３の実アドレスを表すメモリ空間である。物理アドレス空間２５は、ページテーブルエントリ２４によってページ単位にアクセスされる。ここで、実際の物理アドレスへのアクセスは、ページテーブルエントリ２４の上位２０ビットと、仮想アドレス２２の下位１２ビットを足し合わせたものとなる。
【００１４】
図３は、ユーザプログラムのプロセスが有するプロセス仮想空間２１を管理する仕組みを表した図である。この仕組みについては、ＯＳが管理しており、ユーザプログラムのプロセス１つにつき１つの管理情報が割当てられる。管理情報は、ユーザ空間管理情報３１として表され、ユーザプログラムのプロセスが有しているプロセス仮想空間２１の各ブロックの情報を保持する。
ユーザ空間管理情報３１は、空間ブロック情報３２がリンクされて構成される。リンクのリストの先頭は、vm_link３３によって保持される。vm_link３３は、ＯＳ（カーネル）が各プロセスを管理するためのプロセス情報の構造体である、プロセスディスクリプタのメンバとして保持される。プロセスディスクリプタの構造については、各ＯＳ（カーネル）の実装に依存するのでここでは言及しない。
【００１５】
１つの空間ブロック情報３２は、プロセス仮想空間２１において対応するブロックの詳細な情報をメンバとして有する。メンバは、次に示す６つである。
・start３２−１：空間ブロックの先頭の仮想アドレス。
・end３２−２：空間ブロックの終端の仮想アドレス。ＯＳは、start３２−１とEnd３２−２とを使って、プロセスがページフォルトを起こしたアドレスがどの空間ブロック情報３２の領域であるかを判別する。
・dpio_flag３２−３：リードバッファデマンドページング領域フラグ。この空間ブロックがリードバッファデマンドページングに係る領域として使われていることを表すフラグ。
・drvbuf_ptr３２−４：対応するドライババッファの物理アドレス。この空間ブロックがリードバッファデマンドページング領域として使われている場合に、対応するドライババッファの物理アドレスを保持する。
・total_pages３２−５：この空間ブロックについて、まだドライババッファに残っているページの総数。リードバッファデマンドページング用のメモリ空間が確保された時点では、
total_pages = (end - start + 1)÷4096;
if(end & 0x0fff)
total_pages ++;
と初期化され、ページフォルトを契機にユーザ空間に再マップされる毎に１つずつ減っていく。これが０になると、全ての物理ページがユーザ空間にマップされたことになり、dpio_flag３２−３は、０にリセットされる。
・next３２−６：次の空間ブロック情報３２へのリンクポインタ。
【００１６】
空間ブロック情報３２は、昇順にリンクされており、プロセスが新しいメモリ空間を確保するたびにＯＳにより、ユーザ空間管理情報３１に追加される。また、プロセスがメモリ空間を開放した場合には、ユーザ空間管理情報３１から削除される。なお、dpio_flag３２−３がセットされた空間ブロック情報３２を確保するためには、後述するリードバッファデマンドページングバッファ獲得システムコールを使用する必要がある。
【００１７】
図４は、リードバッファデマンドページングバッファ獲得システムコールの処理（デマンドページングバッファ獲得処理）に係るフローチャートを示す図である。リードバッファデマンドページングを利用するユーザプログラムは、このシステムコールで獲得されたバッファアドレスを使用してデータのリード処理を行う。ここで、ステップＳ４０〜ステップＳ４６の処理を説明する。
ステップＳ４０では、ＯＳは、プロセス仮想空間２１に要求されたサイズのメモリ空間が空いているかを確認する。ここで、空きが無い場合、すなわち、ユーザプログラムが使用できるメモリ空間が空いていないと判断した場合、ＯＳは、エラー処理（メモリ不足エラー）を行い（ステップＳ４２）、システムコールを終了する。
他方、空いていると判断した場合は、ＯＳは、その領域を確保し、続いて、ステップＳ４３の処理を行う。なお、先頭アドレスは、ページ単位でアサインされているものとする。多くのカーネルにおいてそのように実装されている理由は、管理が容易だからである。
【００１８】
ステップＳ４３では、ＯＳは、空間ブロック情報３２を確保して初期化する。このとき、各メンバは、以下のように初期化される。
・start３２−１：確保された仮想空間の空間ブロックについて先頭の仮想アドレスが設定される。
・end３２−２：確保された仮想空間の空間ブロックについて終端の仮想アドレスが設定される。
・dpio_flag３２−３：この空間ブロックがリードバッファデマンドページング用に使われるので１が設定される。
・drvbuf_ptr３２−４：ドライババッファについてはまだ確保されていないので０クリアされる。
・total_pages３２−５：次の式により初期化される。
total_pages = (end - start + 1)÷4096;
if(end & 0x0fff)
total_pages ++;
・next３２−６：ユーザ空間管理情報３１への挿入の位置が未定なのでＮＵＬＬに設定される。
【００１９】
ステップＳ４４では、ＯＳは、ステップＳ４３で確保した空間ブロック情報３２をユーザ空間管理情報３１のどの位置に挿入すべきかを判別し、その位置に挿入するために自身のnext３２−６と１つ前の空間ブロック情報３２のnext３２−６とを更新する。
ステップＳ４５では、ＯＳは、ページテーブル２３を更新する。対応するページテーブルエントリ２４は、start３２−１〜end３２−２の範囲にある。また、ページテーブル２３へのインデックスは、
インデックス  ＝  （仮想アドレス  ＆  0xfffff000)  >>  １２
で求められる。
よって、ＯＳは、start３２−１からend３２−２まで４ＫＢの範囲でインデックスを計算し、対応するページテーブルエントリ２４を選び出す。そして、ＯＳは、選び出したページテーブルエントリ２４に対して次の処理を行う。
・属性：ＯＳは、リードオンリの属性（FLAG_RONLY）にする。また、ＯＳは、物理メモリが割当たっていないことを示すフラグ（FLAG_NULL）もセットする。
・物理アドレス：ＯＳは、０をセットする。
このように、ページテーブルエントリ２４を初期化することにより、ユーザプログラムが対応する仮想空間をアクセスしたときに、ページフォルトが発生するように仕向けることができる。
ステップＳ４６では、ＯＳは、ステップＳ４０〜ステップＳ４５で初期化した領域の先頭の仮想アドレスをユーザプログラム（プロセス）に返却する。この値は、start３２−１の値である。
【００２０】
図５は、リードシステムコールが実行された場合において、対応するデバイスドライバの処理（デバイスドライバリード処理）に係るフローチャートを示す図である。ここで、ステップＳ５１〜ステップＳ５５の処理を説明する。
ステップＳ５１では、デバイスドライバは、リードシステムコールがリードバッファデマンドページングを使ったリードシステムコールであるか、又は通常のリードシステムコールであるかを判断する。この判断は、リードシステムコールで渡されたバッファ（read（fd，buf，size））アドレスを表す空間ブロック情報３２のdpio_flag３２−３が１であるか否かを基準に行われる。
ここで、dpio_flag３２−３が０であった場合は、通常のバッファを使った普通のリードシステムコールであると判断できるので、デバイスドライバは、普通のリード処理を行い（ステップＳ５２）、デバイスドライバリード処理を終了する。他方、dpio_flag３２−３が１であった場合は、デバイスドライバは、リードバッファデマンドページングを使ったリードシステムコールであると判断できるので、ステップＳ５３の処理を行う。
【００２１】
ステップＳ５３では、デバイスドライバは、デバイスからデータを取得するのに必要な物理メモリをメモリマネージャから獲得する。これに対応するページテーブル２３は、ＯＳ（カーネル）が管理する自身のメモリ空間になるため、その初期化はメモリマネージャが行う。なお、本実施形態では、より詳細な内容については言及しない。
デバイスドライバは、獲得したドライバ用の物理アドレスを、リードシステムコールを実行したプロセスの対応する空間ブロック情報３２（リードシステムコールで渡されたバッファアドレスから特定できる。）のメンバdrvbuf_ptr３２−４にセットする。
ステップＳ５４では、デバイスドライバは、デバイスからデータを読み出しバッファに格納する。デバイスドライバは、全てのデータを読み出したら、リードサイズをユーザプログラム（プロセス）に返却し（ステップＳ５５）、デバイスドライバリード処理を終了する。
【００２２】
図６は、ページフォルトハンドラでのリードバッファデマンドページング処理に係るフローチャートを示す図である。ここで、ステップＳ６００〜ステップＳ６１２の処理を説明する。
ステップＳ６００では、ＯＳは、ページフォルトを起したプロセスにおいて、ページフォルトを起こしたアドレスが、前記プロセスが有する仮想空間内にあるか否かを判別する。この判別には、ユーザ空間管理情報３１が利用される。
ここで、ページフォルトを起こしたアドレスが、どの空間ブロック情報３２にも含まれない場合は、不正アクセスとみなすことができるので、ＯＳは、不正アクセスに係る処理を行う（ステップＳ６０１）。例えば、ＯＳ（カーネル）によってSIGSEGVシグナルが送られてそのプロセスが消滅する。ページフォルトを起こしたアドレスが、空間ブロック情報３２の１つに一致した（含まれる）場合は、ＯＳは、続いて、ステップＳ６０２の処理を行う。
【００２３】
ステップＳ６０２では、ＯＳは、ページフォルトを起したアドレスが、リードバッファデマンドページングに係るアドレスであるか否かをチェックする。この判定は、対応する空間ブロック情報３２のdpio_flag３２−３が１であるか否かで判断できる。ここで、dpio_flag３２−３が０であった場合は、ＯＳは、リードバッファデマンドページングで使用しない領域でのページフォルトであると判断できるので、通常のページフォルト処理を行う（ステップＳ６０３）。なお、リードバッファデマンドページングで使用しない領域でのページフォルトは、多くの場合、通常のデマンドページングかスワップアウトされたメモリへのアクセスにより発生する。他方、dpio_flag３２−３が１であった場合は、ＯＳは、リードバッファデマンドページングで使用する領域でのページフォルトあるので、ステップＳ６０４の処理を行う。
ステップＳ６０４では、ＯＳは、ページフォルトを起こしたアドレスからページテーブルエントリ２４のインデックスを算出する処理を行う。算出には、次の式が使用される。
Index  ＝  （ページフォルトを起こしたアドレス  ＆  0xfffff000）  >>  １２；
【００２４】
ＯＳは、算出したインデックスをローカル変数Indexに保存する。ステップＳ６０５では、ＯＳは、ステップＳ５３で確保されたドライババッファ内での位置を算出する処理を行う。算出には、次の式が使用される。
Offset  ＝  ページフォルトを起こしたアドレス  −  start３２−１；
ＯＳは、算出した位置をローカル変数Offsetに保存する。ステップＳ６０６では、ＯＳは、ページテーブル２３にセットする物理メモリアドレス（ページ単位）を算出する処理を行う。ページテーブル２３にセットする値は、ステップＳ６０５で算出したOffsetとドライババッファの先頭アドレスとから算出することができる。算出には、次の式が使用される。
page_address  ＝  （drvbuf_ptr  ＋  Offset）  ＆  0xfffff000；
ＯＳは、算出したアドレスをローカル変数page_addressに保存する。ステップＳ６０７では、ＯＳは、ステップＳ６０４〜ステップＳ６０６で算出した値を使って、ページテーブルエントリ２４に物理メモリのアドレスをセットする。
ページテーブル［index］  ＝  page_address；
ステップＳ６０８では、ＯＳは、ステップＳ６０７でセットしたページテーブルエントリ２４に属性を再設定する処理を行う。より具体的には、ＯＳは、属性をFLAG_RWにして、かつFLAG_NULLを消す。
【００２５】
ステップＳ６０９では、ＯＳは、ドライババッファに割当てていた物理ページをユーザ空間に再マップした（割り付けた）ため、ＯＳ（カーネル）のアドレス空間内のこの物理ページに対応するページテーブルエントリ２４をリセットする。リセットにより、物理アドレスには０、属性にはFLAG_NULLが設定される。この構成によれば、ページフォルトをきっかけにして物理メモリをドライババッファからユーザ空間に再マップを行えるようになる。その結果、物理メモリ間のコピー処理を省略することができる。
ステップＳ６１０では、ＯＳは、total_pages３２−５を１つ減じる。これは、ＯＳが１つの物理ページの再マップを終了したからである。
ステップＳ６１１では、ＯＳは、引き続きtotal_pages３２−５のチェックを行う。total_pages３２−５が０であった場合、ＯＳは、リードバッファデマンドページング領域の全物理ページを再マップし終わったと判断できるので、dpio_flag３２−３を０クリアし、devbuf_ptrもＮＵＬＬにする（ステップＳ６１２）。これにより以降のこの領域に関するアクセスについては、ステップＳ６０４〜ステップＳ６１２の処理（再マップに係る処理）が行われなくなる。
【００２６】
以上の処理が終了した後は、ＯＳは、ページフォルトを起したプロセスを再実行する。再実行したプロセスには、今度は物理メモリが正しく割当たっているため、今度はページフォルトを起さずに処理を行うことができる。その後、ユーザプログラムは、リードバッファ内の違うページにアクセスすることがある。その場合も、やはりページフォルトが発生し、ＯＳ（カーネル）がステップＳ６００〜ステップＳ６１２の処理を経て、ドライバの物理ページが再マップされる。このように、物理ページがユーザ空間へと順次再マップされていく。
本実施形態の構成によれば、ユーザ空間とカーネル空間とのデータのコピーを最小限に抑えて処理スピードを向上させ、さらに物理メモリを無駄に確保しなくなるのでメモリの使用量を大幅に削減することが可能となる。
【００２７】
（第２の実施形態）
第１の実施形態で説明した構成は、リードサイズがページサイズ以上の場合に特に有効である。仮にページサイズ以下のリード要求があった場合は、デマンドページング処理がかえって負荷になる場合があるので、その場合は次のようにする。
・ＯＳは、リードシステムコール時にサイズをチェックする。
・ページサイズ以下のリード要求であった場合は、ＯＳは、デマンドページングを利用せずに、ドライババッファの物理メモリをリードシステムコール時にユーザ空間（ユーザプログラム）にマッピングする。
・ＯＳは、読み込むことができたサイズを返却する。
この構成によれば、ページフォルトを待たずにユーザ空間に物理ページを再マップすることが可能となるので、ページフォルト発生を抑制できる分だけ処理をより効率化することができる。
以上のように、本実施形態によれば、ユーザ空間とカーネル空間とのデータのコピーを最小限に抑えて処理スピードを向上させ、さらに物理メモリを無駄に確保しなくなるので、メモリの使用量を大幅に削減することが可能となる。
【００２８】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００２９】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図１】
2011118625.tif 000003
【図２】
2011118625.tif 000004
【図４】
2011118625.tif 000005
【図５】
2011118625.tif 000006
【図６】
2011118625.tif 000007
【図３】
2011118625.tif 000008