(57)【要約】【課題】コンピューティングデバイスにデータを記憶する方法を提供する。【解決手段】本方法は、コンピューティングデバイスのページング不能カーネルメモリにメモリファイルシステムを作成するステップと、メモリファイルシステムにデータを書き込むステップと、書き込まれたデータを、コンピューティングデバイス上で実行されているユーザプロセスにアロケートされているページング可能メモリ空間へ転送するステップとを含む。このような設計の利点は、まず、メモリベースのファイルシステムのデータをページング不能カーネルメモリに保持することができ、コンテキストスイッチを実行する必要が最小にされることである。一方、ファイルシステムによって使用されるカーネルメモリの量を最小にすることができるように、必要なときにページング可能メモリへデータを転送することができる。【選択図】図３
2009026310.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティングデバイスにデータを記憶する方法であって、
前記コンピューティングデバイスのページング不能カーネルメモリに、メモリファイルシステムを作成することと、
前記メモリファイルシステムに、データを書き込むことと、
前記書き込まれたデータを、前記コンピューティングデバイス上で実行されているユーザプロセスにアロケートされているページング可能メモリ空間へ転送することと
を含む方法。
【請求項２】
メタデータを前記ファイルシステムに書き込むこと
をさらに含み、
前記書き込まれたデータを転送することは、
前記メタデータ以外のデータを転送すること
を含む
請求項１に記載の方法。
【請求項３】
前記メタデータは、
スーパーブロック、シリンダグループまたはｉｎｏｄｅデータ
を含む
請求項２に記載の方法。
【請求項４】
前記ユーザプロセスを生成することと、
前記ページング可能メモリ空間を、このユーザプロセスに割り当てることと
をさらに含む請求項１に記載の方法。
【請求項５】
前記メモリファイルシステムを作成することは、
バッファキャッシュによって占有されるメモリに、ＵＮＩＸ（登録商標）ファイルシステムを作成すること
を含む
請求項１に記載の方法。
【請求項６】
前記メモリファイルシステムを作成することは、
ＭｅｍＦＳマウントコマンドを使用して、ＵＮＩＸ（登録商標）ファイルシステムを作成すること
を含む
請求項１に記載の方法。
【請求項７】
前記バッファキャッシュメモリの他の部分の使用データとは別個の前記メモリファイルシステムに関する前記使用データを維持すること
をさらに含む請求項５に記載の方法。
【請求項８】
前記ページング可能メモリ空間へ転送された前記メモリファイルシステムのデータファイルのマッピングを維持すること
をさらに含む請求項１に記載の方法。
【請求項９】
前記ファイルシステムに記憶されているデータが所定のしきい値に達することに応答して、前記書き込まれたデータを、前記ページング可能メモリ空間へ転送すること
をさらに含む請求項１に記載の方法。
【請求項１０】
前記書き込まれたデータを前記ページング可能メモリ空間へ転送することは、このデータが、前記ファイルシステムの複数の最長時間未使用ページのうちの１つを含むときに実行される
請求項１に記載の方法。
【請求項１１】
前記データが、前記ページング可能メモリ空間へ転送されると、このデータのページングを阻止すること
をさらに含む請求項１に記載の方法。
【請求項１２】
前記メモリファイルシステムを、前記ページング不能カーネルメモリから除去すること
をさらに含む請求項１に記載の方法。
【請求項１３】
前記データは、
テンポラリファイルデータ
を含む
請求項１に記載の方法。
【請求項１４】
コンピューティングデバイスのバッファキャッシュであって、
バッファキャッシュメモリとして使用するように構成される第１の部分と、
メモリファイルシステムを記憶するようにインプリメントされる第２の部分と、
前記第１の部分及び前記第２の部分のそれぞれに関する別個の使用データと
を備えるバッファキャッシュ。
【請求項１５】
コンピューティングデバイスに関連付けられるプロセッサによって実行されると、該コンピューティングデバイスにメモリ管理システムをインプリメントするプログラムコードを記憶するコンピュータ可読媒体であって、
前記プログラムコードは、
実行されると、前記コンピューティングデバイスに関連付けられるページング不能カーネルメモリにメモリファイルシステムを作成するユーティリティを提供する第１のプログラム命令と、
実行されると、前記メモリファイルシステムの前記データを、前記コンピューティングデバイス上で実行されているユーザプロセスにアロケートされているページング可能メモリ空間へ転送するプロセスを提供する第２のプログラム命令と
を含む
コンピュータ可読媒体。
【請求項１６】
前記第１のプログラム命令は、実行されると、バッファキャッシュによって占有される前記コンピューティングデバイスのメモリに、ＵＮＩＸ（登録商標）ファイルシステムを作成するためのユーティリティを提供する
請求項１５に記載のコンピュータ可読媒体。
【請求項１７】
前記第２のプログラム命令は、実行されると、前記ファイルシステムに記憶されているデータが所定のしきい値に達することに応答して、前記メモリファイルシステムの前記データを前記ページング可能メモリ空間へ転送するプロセスを提供する
請求項１５に記載のコンピュータ可読媒体。
【請求項１８】
前記第２のプログラム命令は、実行されると、前記データが前記ファイルシステムの複数の最長時間未使用ページのうちの１つを含むときに、前記メモリファイルシステムの前記データを前記ページング可能メモリ空間へ転送するプロセスを提供する
請求項１５に記載のコンピュータ可読媒体。
【請求項１９】
実行されると、前記データが前記ページング可能メモリ空間へ転送されるたときに、このデータのページングを阻止するプロセスを提供する第３のプログラム命令をさらに含むプログラムコードを記憶する
請求項１５に記載のコンピュータ可読媒体。
【請求項２０】
実行されると、バッファキャッシュメモリとして使用するように構成される第１の部分と、前記メモリファイルシステムを記憶するようにインプリメントされる第２の部分と、前記第１の部分及び前記第２の部分のそれぞれに関する別個の各使用データとを有するバッファキャッシュをインプリメントする第３のプログラム命令をさらに含むプログラムコードを記憶する
請求項１５に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピューティングデバイスにデータを記憶する方法に関する。
【背景技術】
【０００２】
コンパイラ及びエディタ等のアプリケーションは、その実行中に、テンポラリファイル等の一時的なファイルを作成する。
これらのファイルの性質によって、このようなアプリケーションは、ディスクからそれらのファイルにアクセスしなければならないのではなく、それらのファイルが１次メモリに記憶されることでファイルに素早くアクセスすることができ、利益を受けることができる。
１次メモリのアクセスはディスクアクセスよりもはるかに高速であるので、大幅な性能向上を達成することができる。
【０００３】
テンポラリファイルを１次メモリに記憶することができる方法には、従来２つの方法がある。
第１の方法は、ＲＡＭディスク（１次メモリをストレージとして使用するデバイスドライバ）を作成することである。
この場合、ＲＡＭディスク上にファイルシステムを構築することができ、すべてのファイルシステムアクセスは１次メモリから行われる。
【０００４】
第２の手法は、ページング可能メモリを使用してファイルシステムデータを記憶するメモリベースのファイルシステムを作成することである。
メモリベースのファイルシステムは、１次メモリの大部分を占有する可能性があるので、利用可能なシステムメモリの他の消費者が影響を受けないことを確実にするために、メモリファイルシステムのページをページアウトすることができることが必要である。
ページング可能メモリは、ユーザプロセスのアロケートされる仮想メモリ又はカーネルの無名メモリのいずれかとして利用可能にすることができる。
【０００５】
Ｌｉｎｕｘ、Ｓｏｌａｒｉｓ、及びＮｅｔＢＳＤで利用可能なｔｍｐｆｓ等の現代のメモリベースのファイルシステムは、カーネルの無名メモリを利用してファイルシステムデータを記憶する。
【０００６】
カーネルの無名メモリをアロケートすることができないオペレーティングシステムにインプリメントされるメモリベースのファイルシステムは、２つの従来の技法のうちの一方を使用する。
第１の技法では、ファイルシステムデータファイル及びメタデータが、ユーザプロセス仮想メモリに記憶され、仮想メモリシステムがメモリを解放する必要があるときは、ファイルシステムデータファイル及びメタデータをスワップデバイスへトランスペアレントにスワップすることができる。
【０００７】
第２の技法では、ファイルシステムデータ及びメタデータは、カーネルページに記憶され、別個のスワップデバイスへのページングは、別個にインプリメントされるページングシステムを使用して実行される。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、ユーザプロセス仮想メモリを使用して動作する従来のメモリベースのファイルシステムに関する不利な点は、データファイルが複製される可能性があり、一方のコピーをファイルシステム（ユーザプロセス仮想メモリ）に有し、別のコピーを、ファイルシステムへの転送をバッファリングするのに使用されるオペレーティングシステムのバッファキャッシュに有することになるということである。
これは、１次メモリの非効率的な使用である。
【０００９】
一時的なファイルをユーザプロセス仮想メモリに記憶することに関するさらなる不利な点は、メモリファイルシステムに属するバッファの読み出し又は書き込みごとにコンテキストスイッチが存在する必要があり、これがメモリファイルシステムの性能に影響を与えるということである。
これは、オペレーティングシステムカーネルが、現在実行中のプロセスのユーザプロセス仮想メモリ空間以外のユーザプロセス仮想メモリ空間からデータをページインすることがないためである。
したがって、仮想メモリがファイルシステムを記憶するのに使用されるユーザプロセスへのコンテキストスイッチは、読み出しオペレーション又は書き込みオペレーションごとに必要とされる。
【課題を解決するための手段】
【００１０】
本発明にかかる方法は、上述のような背景からなされたものであって、コンピューティングデバイスにデータを記憶する方法であって、前記コンピューティングデバイスのページング不能カーネルメモリに、メモリファイルシステムを作成することと、前記メモリファイルシステムに、データを書き込むことと、前記書き込まれたデータを、前記コンピューティングデバイス上で実行されているユーザプロセスにアロケートされているページング可能メモリ空間へ転送することとを含む。
【発明を実施するための最良の形態】
【００１１】
図１は、サーバ又はワークステーション等の処理システム１の概略図である。
システム１はプロセッサ２を備える。
プロセッサ２は、中央処理装置ＣＰＵ３、内部キャッシュメモリ４、変換索引バッファＴＬＢ５、及び、バス７にインターフェースするバスインターフェースモジュール６を含む。
また、バス７には、１次メモリ８及びハードディスク９もインターフェースされている。
１次メモリ８は、メインメモリ又は物理メモリとも呼ばれ、この例では、ランダムアクセスメモリ（ＲＡＭ）である。
ＲＡＭ８は、バッファキャッシュ１０としてアロケートされている部分を含む。
バッファキャッシュ１０は、ハードディスク９へ及びハードディスク９から転送されるデータをバッファリングするバッファをインプリメントするのに使用される。
このバッファキャッシュは、通常、１つ又は複数のフリーリストを使用して、自身のメモリ空間の使用を制御する。
ただし、代替的な実施態様を使用することができる。
システムは、通常、バスにインターフェースされているさまざまな他の入出力サブシステム１１も含み、これらの入出力サブシステム１１は、システムのオペレーションに必要とされる。
【００１２】
図１は例示にすぎないこと、及び、本発明は、この示されたシステムに限定されるものではなく、別法では、複数のプロセッサを有するシステム又はネットワーク上で動作するシステム等、より複雑なシステムにも適用することができることが理解されるべきである。
【００１３】
図２は、ソフトウェアとハードウェアとの間の相互関係を示す処理システムの高レベルの概観である。
このシステムは、ハードウェア２０、カーネル２１、及びアプリケーションプログラム２２を含む。
ハードウェアは、システムのハードウェアレベルにあるものとして参照され、図１に示すハードウェアシステム構成要素を含む。
カーネル２１は、カーネルレベルにあるものとして参照され、オペレーティングシステムのハードウェアを制御する部分である。
処理システム上で実行されるアプリケーションプログラム２２は、ユーザレベルにあるものとして参照される。
【００１４】
図１に示す処理システム１のキャッシュメモリ４、メインメモリ８、及びハードディスク９は、すべて、プログラム命令及びデータを記憶することができる。
これらのプログラム命令及びデータは、合わせてデータと総称される。
これらのメモリ内のデータの処理は、メモリ管理システムによってハンドリングされる。
このメモリ管理システムは、カーネルレベルで従来と同様に動作する。
【００１５】
図３を参照すると、本発明による処理システムのメモリ管理システム３０が概略的に示されている。
メモリ管理システム３０は、オペレーティングシステムのカーネルモード３１、すなわちカーネルレベルで動作すると共に、オペレーティングシステムのユーザモード３２、すなわちユーザレベルで動作する。
カーネルモード３１には、カーネルファイルシステムコンポーネント３３が設けられている。
この場合には、ＨＰ−ＵＸ  Ｕｎｉｘ（登録商標）ベースのオペレーティングシステムのＭｅｍＦＳファイルシステムコンポーネントが設けられている。
このカーネルファイルシステムコンポーネント３３は、処理システムのバッファキャッシュ１０でオペレーションを実行する。
ＭｅｍＦＳスワップドライバ３４はカーネルレベル３１で実行され、アロケートされているアドレス空間３６を有するユーザプロセス３５は、ユーザレベル３２で実行される。
ユーザ空間デーモン３７及びカーネルデーモン３８は、それぞれユーザモード３２及びカーネルモード３１でインプリメントされる。
これらは、ユーザの直接の制御下にあるのではなく、オペレーティングシステムのバックグラウンドで実行されると共に、以下で詳細に説明するように、必要なときにメモリ管理タスクを実行するプロセスである。
【００１６】
ここで、図４を参照して、メモリ管理システム３０のオペレーションを説明する。
【００１７】
カーネルファイルシステムコンポーネント３３、すなわちＭｅｍＦＳファイルシステムをインプリメントして、バッファキャッシュ１０にファイルシステムを作成する（ステップ１００）。
本例では、これは、たとえばユーザによって起動されるＵｎｉｘ（登録商標）マウントコマンドラインユーティリティのマウントシステムコールによって実行される。
マウントユーティリティは、バッファキャッシュ１０にファイルシステムを作成すると、新しいユーザプロセス３５をフォークする（ステップ１１０）。
このユーザプロセス３５のユーザプロセスメモリは、テンポラリファイルを保持するのに使用することができる。
本例では、ユーザプロセス３５は、ＭｅｍＦＳスワップドライバ３４に対してｉｏｃｔｌコール３９を行い、ｉｏｃｔｌ関数にある間、バックグラウンドでカーネルデーモン３８として実行を続ける。
カーネルデーモン３８は、スリープして、ｉｏｃｔｌ関数における入出力要求を待つ（ステップ１２０）。
ｉｏｃｔｌ関数がコールされたとき、マウント時刻にフラグがセットされ、このフラグがセットされている限りｉｏｃｔｌルーチンはループし、終了することはない。
フラグは、たとえば、あらゆるマウントインスタンスに関連付けられる構造に記憶されている。
バークレイソフトウェアディストリビューション（ＢＳＤ）メモリファイルシステム（ＭＦＳ）は、ドライバのｉｏｃｔｌにではなく、そのファイルシステムのマウントルーチンにＩ／Ｏサービス提供ループ（I/O servicing loop）を有し、したがって、ＢＳＤ  ＭＦＳを使用する実施態様は、それに応じて適合される。
【００１８】
メモリファイルシステムがマウントされると、ファイルシステムに書き込まれるデータ及びメタデータは、ユーザモード３２からのファイルシステムコール４０を使用してバッファキャッシュ１０に記憶される。
ＭｅｍＦＳファイルシステムへのすべてのアクセスは、バッファキャッシュ１０を通過する。
このコンテキストにおけるメタデータは、ファイル属性情報を含み、本例では、データファイルごとのｉｎｏｄｅの形に加えて、ファイルシステムのスーパーブロック及びシリンダグループの集まりの形で記憶されているファイル属性情報を含む。
ファイルシステムデータ及びメタデータのページが他のプロセスによって盗まれるのを阻止するために、ファイルシステムのバッファアロケーションは、バッファキャッシュ１０の標準的なバッファフリーリストに対して別個のＭｅｍＦＳフリーリストに記録される（ステップ１４０）。
【００１９】
メモリファイルシステムのページ数が所定のしきい値を超えると（ステップ１５０）、最長時間未使用ページは、ＭｅｍＦＳフリーリストにもはや記録されず、その代わり、バッファキャッシュ１０の最長時間未使用フリーリスト（ＬＲＵフリーリスト）へ移動される（ステップ１６０）。
このしきい値は、本例では、バッファキャッシュ１０が占有することができる最大メモリサイズの或る割合として定義されるシステムカーネル調整可能なものとしてインプリメントされる。
バッファが割り当てられるごとに、バッファキャッシュ１０のＭｅｍＦＳバッファの個数のカウントをこのしきい値に関連して監視することができる。
【００２０】
ＬＲＵフリーリストに記録されたページは、ｂｗｒｉｔｅインターフェースを使用して、ＭｅｍＦＳスワップ擬似ドライバ３４に書き込まれる（ステップ１７０）。
ＭｅｍＦＳスワップ擬似ドライバ３４のストラテジールーチン４１（図３参照）は、ファイルシステムバッファを別個のバッファリストにリンクすることによって要求にサービスする（ステップ１８０）。
このリストは、ユーザプロセス３５のメモリにコピーする必要があるすべての保留中のバッファを記録する。
また、ストラテジールーチン４１は、本例では、標準的なＵＮＩＸ（登録商標）スリープ／ウェークアップメカニズムを使用して、ウェークアップ４２をユーザプロセスデーモンへ送信する（ステップ１９０）。
ユーザプロセスは、目覚めると、バッファキャッシュファイルシステムバッファからデータを受け取り、このデータは、ＭｅｍＦＳスワップ擬似ドライバ３４によって、ユーザプロセス３５のユーザプロセスメモリへ転送される（ステップ２００）。
データバッファのみが、バッファキャッシュ１０からユーザプロセスアドレス空間３５へ転送される。
これによって、メタデータはバッファキャッシュ１０に確実に残り、したがって、メタデータしか関与しないオペレーションは常に高速であることが保証される。
【００２１】
ＲＡＭ８の量は限られており、ユーザプロセス３５等の特定のプログラムに関連付けられるすべてのデータがＲＡＭ８で常に利用可能にされている場合、システムは限られた個数のプログラムしか実行することができない。
したがって、ＨＰ−ＵＸＴＭ等の現代のオペレーティングシステムは仮想メモリ管理システムを作動させ、この仮想メモリ管理システムによって、カーネル２１は、データが必要とされないときはデータ及び命令をＲＡＭ８からハードディスク９又は外部メモリデバイスへ移動させ、必要なときにデータを戻すことが可能になる。
利用可能な全メモリは仮想メモリと呼ばれ、したがって、物理メモリのサイズを超えることができる。
仮想メモリ空間の一部は物理メモリに対応するアドレスを有する。
仮想メモリ空間の残りは、ハードディスク９及び／又は外部メモリデバイスのアドレスにマッピングされる。
以下では、特に指定のない限り、ハードディスクからＲＡＭ８へデータをロードするとの参照はいずれも、他の任意の外部メモリデバイスからＲＡＭ８へデータをロードすることも指すものと解釈されるべきである。
【００２２】
ユーザプロセス３５がコンパイルされるとき、コンパイラはメモリのロケーションを表すプログラムコードの仮想アドレスを生成する。
バッファキャッシュ１０からのデータが、バッファキャッシュ１０からユーザプロセス３５のアドレス空間へ転送されると、そのデータは、それに応じて、オペレーティングシステムの仮想メモリ管理システムによって制御される。
物理メモリ８に利用可能なメモリが十分にない場合には、使用済みメモリを解放しなければならず、解放されるアドレスに保存されているデータ及び命令は、ハードディスク９へ移動される。
通例、物理メモリから移動されるデータは、しばらくの間使用されていないデータである。
【００２３】
オペレーティングシステムが、その後、ユーザプロセス３５等のプログラムを実行している間に仮想アドレスにアクセスしようと試みる時、システムは、特定のアドレスが物理アドレスに対応しているか否かをチェックする。
特定のアドレスが物理アドレスに対応している場合には、システムは、対応している物理アドレスのデータにアクセスする。
仮想アドレスが物理アドレスに対応していない場合には、システムは、ハードディスク９からデータを取り出し、そのデータを物理メモリ８に移動させる。
システムは、その後、通常の方法で物理メモリ８のデータにアクセスする。
【００２４】
ページは、仮想アドレスにマッピングすることができる物理メモリの最小単位である。
たとえば、ＨＰ−ＵＸ（商標）システムでは、ページサイズは４ＫＢである。
したがって、仮想ページは仮想ページ番号ＶＰＮによって参照される一方、物理ページは物理ページ番号ＰＰＮによって参照される。
必要な場合にのみ仮想メモリをメインメモリに移すプロセスは、デマンドページングと呼ばれる。
【００２５】
図５を参照して仮想メモリ管理システムのオペレーションを説明する。
さまざまな種類のメモリ及びデータが記憶される場所を管理するために、ＨＰ−ＵＸ（商標）等のオペレーティングシステムは、ページディレクトリ（ＰＤＩＲ）５０と呼ばれるテーブルをメモリに保持する。
ＰＤＩＲ５０は、現在メモリにあるすべてのページの経過を追跡する。
ページが或る仮想アドレス空間でマッピングされる時、そのページには、ＰＤＩＲ５０のエントリーがアロケートされる。
ＰＤＩＲ５０は、メモリの物理ページをその仮想アドレスにリンクするものである。
【００２６】
ＰＤＩＲ５０はＲＡＭ８に保存される。
システムを高速化するために、ＰＤＩＲ５０のサブセットがプロセッサ２のＴＬＢ５に記憶される。
ＴＬＢ５は仮想アドレスを物理アドレスに変換する。
したがって、各エントリーは、仮想ページ番号及び物理ページ番号の双方を含む。
【００２７】
ＣＰＵ３がメモリページにアクセスしたいとき、ＣＰＵ３は、最初に、ＶＰＮをインデックスとして使用してＴＬＢ５を見る。
物理ページ番号ＰＰＮがＴＬＢ５で見つかる場合、これはＴＬＢヒットと呼ばれ、プロセッサは、必要なページがメインメモリ８にあることを知る。
次に、ページからの必要なデータを、ＣＰＵ３によって使用されるキャッシュ４にロードすることができる。
キャッシュコントローラ５１は、必要なデータをメモリにロードするプロセスを制御することができる。
キャッシュコントローラ５１は、ページがメモリにすでに存在するか否かをチェックする。
ページがメモリに存在しない場合には、キャッシュコントローラ５１は、ＲＡＭ８からデータを取り出して、キャッシュ４に移動させることができる。
【００２８】
ページ番号がＴＬＢ５で見つからない場合、これはＴＬＢミスと呼ばれ、必要なページがＰＤＩＲ５に存在するか否かを調べるために、ＰＤＩＲ５０がチェックされる。
必要なページがＰＤＩＲ５に存在する場合、これはＰＤＩＲヒットと呼ばれ、物理ページ番号がＴＬＢ５にロードされ、ＣＰＵ３によってページにアクセスするための命令が再開される。
必要なページが存在しない場合、これは一般にＰＤＩＲミスと呼ばれ、これは、必要なページが物理メモリ８に存在せず、ハードディスク９又は外部デバイスからメモリに必要なページを移す必要があることを示す。
ハードディスク９からメインメモリ８にページを移すプロセスは、当該技術分野で既知のように、ソフトウェアページフォールトハンドラ５２によって対処され、これに対応して、ＶＰＮ／ＰＰＮエントリーをＰＤＩＲ５０及びＴＬＢ５に作成する。
関連のあるページが物理メモリ８にロードされると、ＣＰＵ３によるアクセスルーチンが再開され、その関連のあるデータをキャッシュ４にロードすることができ、ＣＰＵ３が使用することができる。
【００２９】
本例では、ユーザ空間デーモン３７は、ユーザプロセス３５にアロケートされているページのいずれがワイア（wire）されるべきかを決定するのに使用される。
ワイアードページ（wired page）は、ＰＤＩＲ５０に永久に存在するページであり、したがって、ハードディスク９にページアウトされない。
ＰＤＩＲ５０の特定のページをワイアするためのコマンドインターフェースを作成することができる。
【００３０】
ファイルシステムが、ＭｅｍＦＳコマンドラインユーティリティを使用してアンマウントされた後、ＭｅｍＦＳスワップドライバクローズルーチン（図示せず）がコールされる。
これは、ｉｏｃｔｌルーチンが自身のＩ／Ｏサービス提供ループを終了することができるように、あらゆる保留中のＩ／Ｏ要求をフラッシュして、ファイルシステムがマウントされたときにセットされた、アンマウントコマンドによってコールされたｉｏｃｔｌルーチンのフラグをクリアする。
これによって、ファイルシステムがアンマウントされたことの表示が提供される。
【００３１】
本発明のメモリ管理システム３０は、コンピュータ可読媒体に記憶されているコンピュータプログラムコードとしてインプリメントすることができる。
このプログラムコードは、たとえば、バッファキャッシュ１０にメモリファイルシステムをインプリメントするためのユーティリティ、たとえば、Ｕｎｉｘ（登録商標）アーキテクチャによるＭｅｍＦＳファイルシステムユーティリティ３３を提供することができる。
また、当業者によって理解されるように、このプログラムコードは、上述したようにバッファキャッシュ１０からユーザプロセス仮想メモリ３６へデータを転送するようにインプリメントされるＭｅｍＦＳスワップドライバに加えて、メモリ管理システム３０の他のコンポーネントを提供することができる。
【図面の簡単な説明】
【００３２】
【図１】処理システムの概略図である。
【図２】処理システムの高レベルの概観を示す図である。
【図３】本発明によるメモリ管理システムの概略図である。
【図４】本発明のメモリ管理システムによって実行される処理ステップを示すフロー図である。
【図５】本発明による仮想メモリ管理システムの概略図である。
【符号の説明】
【００３３】
４・・・キャッシュ，
６・・・バスインターフェース，
９・・・ハードディスク，
１０・・・バッファキャッシュ，
１１・・・Ｉ／Ｏ，
３１・・・カーネルモード，
３２・・・ユーザモード，
３３・・・ＭｅｍＦＳファイルシステム，
３４・・・ＭｅｍＦＳスワップドライバ，
３５・・・ユーザプロセス，
３６・・・アドレス空間，
３７・・・ユーザ空間デーモン，
３８・・・カーネルデーモン，
４０・・・ファイルシステムコール，
４１・・・ＭｅｍＦＳスワップストラテジールーチン，
４２・・・ウェークアップ，
５１・・・キャッシュコントローラ，
５２・・・ページフォールトハンドラ，
【図１】
2009026310.tif 000003
【図２】
2009026310.tif 000004
【図３】
2009026310.tif 000005
【図４】
2009026310.tif 000006
【図５】
2009026310.tif 000007
【外国語明細書】
Storing Data 
Background of the Invention
Applications such as compilers and editors create transient files, such as temporary files, during their execution.  Due to the nature of these files, such applications can benefit by having the files stored in primary memory, where they can be quickly accessed, rather than having to access them from a disk.  Since primary memory accesses are much faster than disk accesses, significant performance gains can be achieved.
There are two conventional ways in which temporary files can be stored in primary memory.  A first is to create a RAMdisk (a device driver that uses primary memory as storage).  A filesystem can then be built on the RAMdisk, and all filesystem accesses will be from primary memory.  
A second approach is to create a memory based filesystem that uses pageable memory to store filesystem data.  Since memory based filesystems can occupy a significant portion of the primary memory, the ability to page out the memory filesystem pages is necessary to ensure that other consumers of the available system memory are not affected.  Pageable memory can be made available either as allocated virtual memory of a user process or as kernel anonymous memory.
Modern memory based filesystems such as tmpfs, available on Linux, Solaris and NetBSD, make use of kernel anonymous memory to store filesystem data.  
Memory based filesystems that are implemented in operating systems where kernel anonymous memory cannot be allocated employ one of two conventional techniques.  In a first technique, filesystem data files and metadata are stored in user-process virtual memory, and can be transparently swapped to a swap device when the virtual memory system needs to free memory.  
In a second technique, filesystem data and metadata are stored in kernel pages and paging to a separate swap device is performed using a separately implemented paging system.  
However, a disadvantage with conventional memory based filesystems that operate using user process virtual memory is that they can result in data files being duplicated, having one copy in the filesystem (the user process virtual memory) and a further copy in buffer cache of the operating system, used to buffer transfers to the filesystem.  This is an inefficient usage of the primary memory. 
A further disadvantage with storing transient files in user-process virtual memory is that there needs to be a context switch for every read or write of the buffer belonging to the memory filesystem, which affects its performance.  This is because operating system kernels cannot page-in data from a user process virtual memory space other than that of a currently running process.  A context switch to the user process whose virtual memory is used to store the filesystem is therefore required for each read or write operation.  
Brief Description of Drawings
Figure 1 is a schematic illustration of a processing system;
Figure 2 is a high-level overview of a processing system;
Figure 3 is a schematic illustration of a memory management system according to the present invention;
Figure 4 is a flow diagram illustrating the processing steps performed by the memory management system of the present invention; and
Figure 5 is a schematic illustration of a virtual memory management system according to the present invention.
Detailed Description of the Invention
Figure 1 is a schematic illustration of a processing system 1, such as a server or workstation.  The system 1 comprises a processor 2 including a central processing unit CPU 3, an internal cache memory 4, a translation lookaside buffer TLB 5 and a bus interface module 6 for interfacing to a bus 7.  Also interfaced to the bus 7 is primary memory 8, also referred to as main or physical memory, in this example random access memory (RAM), and a hard disk 9.  The RAM 8 includes a portion allocated as buffer cache 10, used to implement buffers for buffering data being transferred to and from the hard disk 9.  The buffer cache typically controls usage of its memory space using one or more free-lists, although alternative implementations can be used.  The system typically also includes a variety of other input/output subsystems 11 interfaced to the bus, which are required for the operation of the system.  
It should be understood that Figure 1 is exemplary only and that the invention is not limited to the illustrated system, but could alternatively be applied to more complex systems such as those having multiple processors or operating over a network. 
Figure 2 is a high-level overview of a processing system illustrating the inter-relationship between software and hardware.  The system includes hardware 20, a kernel 21 and application programs 22.  The hardware is referred to as being at the hardware level of the system and includes the hardware system elements shown in Figure 1.  The kernel 21 is referred to as being at the kernel level and is the part of the operating system that controls the hardware.  The application programs 22 running on the processing system are referred to as being at a user level.  
The cache memory 4, main memory 8 and hard disk 9 of the processing system 1 shown in Figure 1 are all capable of storing program instructions and data, generally referred to together as data.  Processing of data within these memories is handled by memory management systems, which conventionally operate at the kernel level.  
Referring to Figure 3, a memory management system 30 of a processing system according to the present invention is schematically illustrated.  The memory management system 30 operates in the kernel mode 31 of an operating system, or at the kernel level, as well as in the user mode 32 of the operating system, or at the user level.  In the kernel mode 31, a kernel filesystem component 33 is provided, in this case the MemFS filesystem component of the HP-UX Unix-based operating system, which performs operations on the buffer cache 10 of the processing system.  A MemFS swap driver 34 runs at the kernel level 31 and a user process 35, having an allocated address space 36, runs at the user level 32.  A user space daemon 37 and a kernel daemon 38 are implemented in the user mode 32 and kernel mode 31 respectively.  These are processes that run in the background of the operating system, rather than being under the direct control of the user, and perform memory management tasks when required, as explained in detail below.
Operation of the memory management system 30 will now be described with reference to Figure 4.
The kernel filesystem component 33, namely the MemFS filesystem, is implemented to create a filesystem in the buffer cache 10 (step 100).  In the present example, this is performed by a mount system call of the Unix mount command line utility, for instance invoked by a user.  Having created the filesystem in the buffer cache 10, the mount utility forks a new user process 35 (step 110), whose user process memory can be used to hold temporary files.  In the present example, the user process 35 makes an ioctl call 39 to the MemFS swap driver 34 and, while in the ioctl function, continues running as the kernel daemon 38 in the background that will sleep, waiting for input/output requests in the ioctl function (step 120).  A flag is set at mount time, when the ioctl function is called, and as long as this flag is set the ioctl routine will loop and will not terminate.  The flag is, for instance, stored in a structure that is associated with every mount instance.  The Berkeley Software Distribution (BSD) memory file system (MFS) has an I/O servicing loop in the mount routine of the filesystem, rather than in an ioctl of a driver, and therefore implementations using the BSD MFS would be adapted accordingly.
Once the memory filesystem has been mounted, data and metadata to be written to the filesystem will be stored in the buffer cache 10 using filesystem calls 40 from the user mode 32.  All accesses to the MemFS filesystem will go through the buffer cache 10.  Metadata in this context comprises file attribute information, in the present example stored in the form of an inode for each datafile, as well as a superblock and a collection of cylinder groups for the filesystem.  To prevent pages of the filesystem data and metadata from being stolen by other processes, buffer allocations for the filesystem are recorded in a separate MemFS free list to the standard buffer free-list of the buffer cache 10 (step 140).
When the number of pages in the memory filesystem exceed a predetermined threshold (step 150), least recently used pages are no longer recorded in the MemFS free list and are instead moved to the least recently used free list (LRU free list) of the buffer cache 10 (step 160).  The threshold is, in the present example, implemented as a system kernel tunable defined as a percentage of the largest memory size that the buffer cache 10 can occupy.  A count of the number of MemFS buffers in the buffer cache 10 can be monitored in relation to this threshold every time a buffer is assigned.       
Pages recorded in the LRU free list are written, using the bwrite interface, to the MemFS swap pseudo driver 34 (step 170).  The strategy routine 41 (see Figure 3) of the MemFS swap pseudo driver 34 will service the request by linking the filesystem buffer onto a separate buffer list (step 180), the list recording all pending buffers that need to be copied to the memory of the user process 35.  The strategy routine 41 will also send a wake-up 42 to the user process daemon, in the present example using a standard UNIX sleep/wakeup mechanism (step 190).  The user process, when awoken, will receive data from the buffer cache filesystem buffer, the data being transferred by the MemFS swap pseudo driver 34 to the user process memory of the user process 35 (step 200).   Only data buffers are transferred from the buffer cache 10 to the user process address space 35.  This ensures that metadata remains in the buffer cache 10 and accordingly that operations which involve only metadata will always be fast.  
The amount of RAM 8 is limited and if all the data associated with a particular program, such as the user process 35, is made available in the RAM 8 at all times, the system could only run a limited number of programs.  Modern operating systems such as HP-UXTM therefore operate a virtual memory management system, which allows the kernel 21 to move data and instructions to the hard disk 9 or external memory devices from the RAM 8 when the data is not required, and to move it back when needed.  The total memory available is referred to as a virtual memory and can therefore exceed the size of the physical memory.  Some of the virtual memory space has corresponding addresses in the physical memory.  The rest of the virtual memory space maps onto addresses on the hard disk 9 and/or external memory device.  Hereinafter, any reference to loading data from the hard disk into RAM 8 should also be construed to refer to loading data from any other external memory device into RAM 8, unless otherwise stated.
When the user process 35 is compiled, the compiler generates virtual addresses for the program code that represent locations in memory.  Once the data from the buffer cache 10 has been transferred from the buffer cache 10 to the address space of the user process 35, the data will accordingly be controlled by the virtual memory management system of the operating system.  If there is not enough available memory in the physical memory 8, used memory has to be freed and the data and instructions saved at the addresses to be freed are moved to the hard disk 9.  Usually, the data that is moved from the physical memory is data that has not been used for a while.
When the operating system then tries to access the virtual addresses while running a program such as the user process 35, the system checks whether a particular address corresponds to a physical address.  If it does, it accesses the data at the corresponding physical address.  If the virtual address does not correspond to a physical address, the system retrieves the data from the hard disk 9 and moves the data into the physical memory 8.  It then accesses the data in the physical memory 8 in the normal way.  
A page is the smallest unit of physical memory that can be mapped to a virtual address.  For example, on the HP-UX(tm) system, the page size is 4KB.  Virtual pages are therefore referred to by a virtual page number VPN, while physical pages are referred to by a physical page number PPN.  The process of bringing virtual memory into main memory only as needed is referred to as demand paging.
Operation of a virtual memory management system will be described with reference to Figure 5.  To manage the various kinds of memory and where the data is stored, an operating system, such as HP-UX(tm) maintains a table in memory called the Page Directory (PDIR) 50 that keeps track of all pages currently in memory.  When a page is mapped in some virtual address space, it is allocated an entry in the PDIR 50.  The PDIR 50 is what links a physical page in memory to its virtual address.  
The PDIR 50 is saved in RAM 8. To speed up the system, a subset of the PDIR 50 is stored in the TLB 5 in the processor 2.  The TLB 5 translates virtual to physical addresses. Therefore, each entry contains both the virtual page number and the physical page number.  
When the CPU 3 wishes to access a memory page, it first looks in the TLB 5 using the VPN as an index.  If a physical page number PPN is found in the TLB 5, which is referred to as a TLB hit, the processor knows that the required page is in the main memory 8.  The required data from the page can then be loaded into the cache 4 to be used by the CPU 3.  A cache controller 51 may control the process of loading the required data into memory.  The cache controller 51 will check whether the page already exist in memory.  If not, the cache controller 51 can retrieve the data from the RAM 8 and move it into the cache 4.
If the page number is not found in the TLB 5, which is referred to as a TLB miss, the PDIR 50 is checked to see if the required page exists there.  If it does, which is referred to as a PDIR hit, the physical page number is loaded into the TLB 5 and the instruction to access the page by the CPU 3 is restarted again.  If it does not exist, which is generally referred to as a PDIR miss, this indicates that the required page does not exist in physical memory 8, and needs to be brought into memory from the hard disk 9 or from an external device.  The process of bringing a page from the hard disk 9 into the main memory 8 is dealt with by a software page fault handler 52 and causes corresponding VPN/PPN entries to be made in the PDIR 50 and TLB 5, as is well known in the art.  When the relevant page has been loaded into physical memory 8, the access routine by the CPU 3 is restarted and the relevant data can be loaded into the cache 4 and used by the CPU 3.
In the present example, the user space daemon 37 is used to determine which of the pages allocated to the user process 35 should be wired.  A wired page is one that permanently resides in the PDIR 50 and is therefore not paged out to the hard disk 9.  Command interfaces can be created to wire specific pages in the PDIR 50. 
After the filesystem has been unmounted using the MemFS command line utility, a MemFS swap driver close routine (not illustrated) will be called.  This will flush any pending I/O requests and clear the flag of the ioctl routine called by the unmount command that was set at the time the filesystem was mounted, such that the ioctl routine can terminate its I/O servicing loop, which provides an indication that the filesystem is unmounted.
The memory management system 30 of the present invention may be implemented as computer program code stored on a computer readable medium.  The program code can, for instance, provide a utility for implementing the memory filesystem in the buffer cache 10, for instance the MemFS filesystem utility 33 according to the Unix architecture.  The program code can also provide the MemFS swap driver implemented for transferring data from the buffer cache 10 to the user process virtual memory 36 as previously described, as well as other components of the memory management system 30, as would be understood by the person skilled in the art.    
Claims
1.    A method of storing data in a computing device, the method comprising:
creating a memory file system in non-pageable kernel memory of the computing device;
writing data to the memory file system; and
transferring the written data to a pageable memory space allocated to a user process running on the computing device.
2.    A method according to claim 1, further comprising writing metadata to the file system and wherein the step of transferring the written data comprises transferring data other than the metadata. 
3.    A method according to claim 2, wherein the metadata comprises superblock, cylinder group or inode data.
4.    A method according to claim 1, further comprising:
generating the user process and assigning the pageable memory space to the user process.
5.    A method according to claim 1, wherein creating a memory file system comprises creating a UNIX file system in memory occupied by buffer cache.
6.    A method according to claim 1, wherein creating a memory file system comprises creating a UNIX file system using an MemFS mount command. 
7.    A method according to claim 5, further comprising maintaining usage data relating to the memory file system separate from the usage data of other portions of the buffer cache memory.
8.    A method according to claim 1, further comprising maintaining a mapping of data files of the memory file system that have been transferred to the pageable memory space.   
9.    A method according to claim 1, further comprising transferring the written data to the pageable memory space in response to data stored in the file system reaching a predetermined threshold.      
10.    A method according to claim 1, wherein transferring the written data to the pageable memory space is performed when the data comprises one of a plurality of least recently used pages in the file system.
11.    A method according to claim 1, further comprising preventing paging of the data once it has been transferred to the pageable memory space.
12.    A method according to claim 1, further comprising removing the memory file system from the non-pageable kernel memory.
13.    A method according to claim 1, wherein the data comprises temporary file data.
14.    A buffer cache for a computing device, the buffer cache comprising: 
a first portion arranged for use as buffer cache memory; 
a second portion implemented for storing a memory file system; and     
separate usage data for each of the first and second portions.
15.    A computer readable medium storing program code for implementing a memory management system in a computing device when executed by a processor associated with the computing device, the program code comprising: 
first program instructions which, when executed, provide a utility for creating a memory file system in non-pageable kernel memory associated with the computing device; and
second program instructions which, when executed, provide a process for transferring the data in the memory file system to a pageable memory space allocated to a user process running on the computing device.
16.    A computer readable medium according to claim 15, wherein the first program instructions, when executed, provide a utility for creating a UNIX file system in memory of the computing device occupied by buffer cache.
17.    A computer readable medium according to claim 15, wherein the second program instructions, when executed, provide a process for transferring the data in the memory file system to the pageable memory space in response to data stored in the file system reaching a predetermined threshold.      
18.    A computer readable medium according to claim 15, wherein the second program instructions, when executed, provide a process for transferring the data in the memory file system to the pageable memory space when the data comprises one of a plurality of least recently used pages in the file system.
19.    A computer readable medium according to claim 15, storing program code further comprising third program instructions which, when executed, provide a process for preventing paging of the data once it has been transferred to the pageable memory space.
20.    A computer readable medium according to claim 15, storing program code further comprising third program instructions which, when executed, implement a buffer cache having a first portion arranged for use as buffer cache memory, a second portion implemented for storing a memory file system, and separate respective usage data for each of the first and second portions. 
Abstract
Storing Data 
The invention provides a method of storing data in a computing device, the method including the steps of creating a memory file system in non-pageable kernel memory of the computing device, writing data to the memory file system and transferring the written data to a pageable memory space allocated to a user process running on the computing device.  An advantage of such a design is that, initially, the data of the memory based file system can be kept in the non-pageable kernel memory, minimising the need to perform context switches.  However, the data can be transferred to pageable memory when necessary, such that the amount of kernel memory used by the file system can be minimised.
(Figure 3)
2009026310.tif 000008
2009026310.tif 000009
2009026310.tif 000010
2009026310.tif 000011
2009026310.tif 000012