(57)【要約】【課題】クラッシュダンプルーチンを実行するメモリがクラッシュ時にアロケートされるデータ処理装置においてクラッシュダンプを実行できるようにする。【解決手段】この方法は、第２のルーチンによって使用されるメモリロケーションを特定する第１のルーチンを実行し、特定されたメモリロケーションを含まないメモリ範囲から第２のルーチンを実行するためのメモリをアロケートし、アロケートされたメモリを使用して第２のルーチンを実行することとを含む。第１のルーチンは、より小さなデータサイズを使用することができ、ダンプされるデータの不揮発性ストレージに対する入出力を行わない。再利用に安全なメモリ範囲が特定されると、そのメモリ範囲に記憶されたデータをダンプし、次に、第２のルーチンを実行するためのメモリをそのメモリ範囲からアロケートして、第２のルーチンの実行に再利用する。【選択図】  図７
2009032252.tif 000002
【特許請求の範囲】
【請求項１】
データ処理装置においてメモリのクラッシュダンプを実行する方法であって、
第２のルーチンによって使用されるデータのメモリロケーションを特定する第１のルーチンを実行することと、
前記特定されたメモリロケーションを含まないメモリ範囲から前記第２のルーチンの実行用メモリをアロケートすることと、
前記アロケートされたメモリを使用して前記第２のルーチンを実行することと
を含み、
前記第１のルーチンは、
ダミークラッシュダンプルーチン
を含み、
前記第２のルーチンは、
クラッシュダンプルーチン
を含む
方法。
【請求項２】
前記ダミークラッシュダンプルーチンは、前記クラッシュダンプルーチンよりも小さなデータサイズを使用する
請求項１に記載の方法。
【請求項３】
前記ダミークラッシュダンプルーチンの前記実行は、カーネルクラッシュによってトリガされる
請求項１に記載の方法。
【請求項４】
前記データ処理装置は、
仮想メモリ管理システム
を備え、
前記データのメモリロケーションを特定する前記ダミークラッシュダンプルーチンを実行することは、
前記ダミークラッシュダンプルーチンによってアクセスされる仮想ページアドレスに対応する物理ページアドレスの記録を作成すること
を含む
請求項１に記載の方法。
【請求項５】
前記ダミークラッシュダンプルーチンを実行することは、
仮想ページアドレスが前記ダミークラッシュダンプルーチンによってアクセスされるときにクラッシュダンプページフォールトハンドラを起動すること
をさらに含み、
前記仮想ページアドレスに対応する前記物理ページアドレスを保存することは、前記クラッシュダンプページフォールトハンドラによって実行される
請求項４に記載の方法。
【請求項６】
前記装置のページテーブルのすべての変換を無効としてマーキングすることであって、前記ダミークラッシュダンプルーチンの期間中に前記クラッシュダンプページフォールトハンドラを起動する、マーキングすること
をさらに含む請求項５に記載の方法。
【請求項７】
前記特定されたメモリロケーションを含まないメモリ範囲を特定することと、
前記クラッシュダンプルーチンの実行用メモリを前記メモリ範囲からアロケートする前に、前記メモリ範囲のデータを不揮発性ストレージに保存することと
をさらに含む請求項１に記載の方法。
【請求項８】
前記クラッシュダンプルーチンの実行用メモリをアロケートすることは、
少なくとも１つの圧縮バッファ用のメモリをアロケートすること
を含む請求項１に記載の方法。
【請求項９】
前記クラッシュダンプルーチンの実行用メモリをアロケートすることは、
並列Ｉ／Ｏの実行用の複数のバッファをアロケートすること
を含む請求項１に記載の方法。
【請求項１０】
前記クラッシュダンプルーチンを実行することは、
圧縮アルゴリズム、並列Ｉ／Ｏオペレーションアルゴリズム、暗号化アルゴリズムおよびネットワークを介して不揮発性ストレージに書き込むアルゴリズムの１つ以上を実行すること
を含む
請求項１に記載の方法。
【請求項１１】
データ処理装置においてメモリのクラッシュダンプをコンピュータに実行させるプログラムであって、
第２のルーチンによって使用されるデータのメモリロケーションを特定する第１のルーチンを実行する処理ユニットと、
前記特定されたメモリロケーションを含まないメモリ範囲から前記第２のルーチン用のメモリをアロケートするメモリアロケータと
を前記コンピュータに実行させ、
前記処理ユニットは、前記メモリアロケータによってアロケートされた前記メモリを使用して前記第２のルーチンを、前記コンピュータにさらに実行させ
前記第１のルーチンは、
ダミークラッシュダンプルーチン
を前記コンピュータに実行させ、
前記第２のルーチンは、
クラッシュダンプルーチン
を前記コンピュータに実行させる
プログラム。
【請求項１２】
前記処理ユニットは、低メモリ動作モードで、前記ダミークラッシュダンプルーチンを、前記コンピュータに実行させるように構成される
請求項１１に記載のプログラム。
【請求項１３】
前記処理ユニットは、前記コンピュータに、仮想メモリアドレスを使用して、前記データ処理装置のメモリにアドレスさせ、
前記モジュールは、
前記コンピュータに、前記ダミークラッシュダンプルーチンの期間中にアクセスされる仮想アドレスに対応する物理アドレスを保存させる内部メモリ
をさらに備える
請求項１１に記載のプログラム。
【請求項１４】
ページフォールトハンドラ
をさらに備え、
前記ページフォールトハンドラは、前記ダミークラッシュダンプルーチンの期間中にアクセスされた仮想アドレスに対応する前記物理アドレスを、前記コンピュータに保存させる
請求項１１に記載のプログラム。
【請求項１５】
前記処理ユニットは、前記コンピュータに、前記データ処理装置のページテーブルのすべての変換を無効としてマーキングさせ、前記ダミークラッシュダンプルーチンの期間中に前記クラッシュダンプページフォールトハンドラを起動させる
請求項１４に記載のモジュール。
【請求項１６】
前記メモリアロケータは、前記コンピュータに、前記特定されたメモリロケーションを含まないメモリ範囲を特定させ、
前記処理ユニットは、前記コンピュータに、実際のダンプの実行用メモリを前記メモリ範囲からアロケートする前に、前記メモリ範囲のデータを、不揮発性ストレージに保存させる
請求項１１に記載のモジュール。
【請求項１７】
カーネルを構成する
請求項１１に記載のプログラム。
【請求項１８】
メモリと、
カーネルと、
前記カーネルのクラッシュ時に、前記メモリの第２の部分のクラッシュダンプに使用される前記メモリの第１の部分をアロケートするメモリアロケータと、
前記カーネルのクラッシュ時に前記メモリの前記第２の部分を不揮発性ストレージに保存するクラッシュダンプモジュールと、
を備える装置であって、
前記クラッシュダンプモジュールは、前記カーネルのクラッシュ時にダミークラッシュダンプルーチンを実行して、クラッシュダンプルーチンを実行するのに使用されるカーネルデータ構造体を特定するようにさらに動作し、
前記メモリアロケータは、前記特定されたカーネルデータ構造体を含まないメモリ範囲を特定して、前記特定されたメモリ範囲から前記クラッシュダンプに使用される前記メモリの前記第１の部分をアロケートする
装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラッシュダンプルーチンを実行するメモリがクラッシュ時にアロケートされるデータ処理装置においてクラッシュダンプを実行できるようにする方法およびその装置に関する。
【背景技術】
【０００２】
ほとんどのオペレーティングシステムは、エンジニアが後にクラッシュの原因を特定することをより容易にするために、クラッシュ時に物理メモリのコンテンツを不揮発性ストレージに保存するためのプロシージャを有する。
このプロシージャは、通常、カーネルのサブシステムによって実行される。
たとえば、カーネルが実行しているプログラムの１つにおける致命的エラーの結果として、カーネルのクラッシュ時に、クラッシュダンプルーチンは、物理メモリのコンテンツを読み出し、そのコンテンツを、専用内部ディスクのような安定したストレージに書き込むか、または、ネットワークを介して外部デバイスに書き込む。
エンジニアは、後に、記憶されたデータであるダンプに対してカーネルデバッガを実行することができる。
【０００３】
クラッシュダンプを実行するためには、メモリが必要である。
従来では、メモリの或るエリアが、この目的のためにシステムの起動時にアロケートされる。
しかしながら、クラッシュを実行するためのメモリ全体が起動時にアロケートされると、アロケートされたメモリは、ランタイム中に他の目的に使用することができない。
この結果、利用可能なメモリ資源の使用は非効率的なものとなる。
この問題は、圧縮、並列入出力、および、ネットワークを介したダンプを利用する、より高度化されたクラッシュダンプルーチンを使用するオペレーティングシステムではさらに悪化する。
その理由は、それらのオペレーティングシステムは、より高いメモリ要件を有し、したがって、さらに多くのメモリがランタイム中に他の目的で利用不能となるからである。
加えて、クラッシュダンプを実行するのに必要なメモリ量の特定は、いくつかの状況では、起動時よりもクラッシュ時の方が容易である。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記問題を克服する試みが行われてきた。
たとえば、ＨＰ−ＵＸＴＭオペレーティングシステムは、ランタイム時ではなくクラッシュ時にダンプを実行するためのメモリをアロケートする。
クラッシュ時に使用するメモリを見つけるためにこのオペレーティングシステムによって使用される技法は、メモリの各ページがどのようなタイプのデータを記憶するのかを経過監視することを伴う。
カーネルは、物理メモリの各ページをその使用に従って分類し、クラッシュ時には、再利用するのに安全であるページのクラスに属するページを容易に特定することができる。
この技法に関する問題は、各ページが属するクラスを経過監視するための記録が、利用可能なメモリの大きな部分を占めるということである。
【課題を解決するための手段】
【０００５】
本願にかかる方法は、上述した背景からなされ、データ処理装置においてメモリのクラッシュダンプを実行する方法であって、第２のルーチンによって使用されるデータのメモリロケーションを特定する第１のルーチンを実行することと、前記特定されたメモリロケーションを含まないメモリ範囲から前記第２のルーチンの実行用メモリをアロケートすることと、前記アロケートされたメモリを使用して前記第２のルーチンを実行することと、を含み、前記第１のルーチンは、ダミークラッシュダンプルーチンを含み、前記第２のルーチンは、クラッシュダンプルーチンを含む。
【０００６】
次に、添付図面を参照して、本発明の実施形態を例として説明する。
【発明を実施するための最良の形態】
【０００７】
図１は、サーバまたはワークステーション等の処理システム１の概略図である。
この処理システム１は、プロセッサ２、たとえばダイナミックＲＡＭの形態のメインメモリ３、ハードディスク４、および、追加の不揮発性ディスク５を備える。
これらは、バス６によって相互接続されている。
不揮発性ディスク５は、クラッシュ時に物理データを保存するのに使用することができる。
システムは、当業者に明らかなように、通常、システムのオペレーションに必要な他のさまざまな入出力（Ｉ／Ｏ）サブシステム７も含む。
プロセッサは、中央処理装置ＣＰＵ８、内部キャッシュメモリ９、変換索引バッファＴＬＢ１０、および、中央バス６とインターフェースするためのバスインターフェースモジュール１１を備える。
【０００８】
図１は例示にすぎず、本発明は、単一のプロセッサのみを有するシステムに限定されるものではないことが理解されるべきである。
本発明は、複数のプロセッサを有するシステムでも実施することができる。
その上、不揮発性ディスク５は、中央バス６の代わりにＩ／Ｏサブシステム７に接続することもできる。
不揮発性ディスク５は、たとえば、ネットワークを介してアクセスすることができ、リモートロケーションに配置することができる。
【０００９】
図２は、ソフトウェアとハードウェアとの間の相互関係を示すコンピュータシステムの高レベルの概観である。
このシステムは、ハードウェアレベル１２、カーネル１３、および、ユーザレベル１４を含む。
ハードウェアレベル１２は、図１に示すハードウェアシステム構成要素を含み、カーネル１３は、ハードウェアを制御するオペレーティングシステムの部分であり、ユーザレベル１４は、コンピュータ上で実行されているアプリケーションプログラムを含む。
プロセッサは、１つまたは複数のプロセスを実行する。
これらプロセスは、実行中のプログラムとして定義することができる。
通常、プロセス自体は多数のスレッドとして実行される。
ここで、スレッドは、オペレーティングシステムスケジューラによって実行のためにスケジューリングすることができるプロセス内のエンティティである。
また、カーネル１３は、以下でより詳細に説明するクラッシュダンプサブシステム１５も含む。
【００１０】
図１に示すキャッシュ９、メインメモリ３、および、ハードディスク４は、すべて、プログラム命令およびデータを記憶することができる。
これらプログラム命令およびデータは通常、合わせてデータと総称される。
データは、Ｉ／Ｏサブシステム７を通じてアクセスされる外部デバイスにも記憶することができる。
カーネル１３のタスクの１つは、メモリ資源へのアクセスを管理することである。
プロセスまたはスレッドを実行するには、そのプロセスまたはスレッドに必要なデータが、ＣＰＵ８に利用可能であるように、実行時にメインメモリ３に存在しなければならない。
メインメモリ３は、物理メモリとも呼ばれる。
カーネル１３自体が、起動時にメモリにロードされると、カーネル１３は、所望のプロセスまたはスレッドを実行するのに必要な他のあらゆるデータが物理メモリ３に確実に移されるようにする。
しかしながら、ＲＡＭの量は限られており、特定のプログラムに関連付けられるすべてのデータが、ＲＡＭで最初から利用可能にされている場合、システムは、限られた個数のプログラムしか実行することができない。
したがって、ＨＰ−ＵＸＴＭ等の現代のオペレーティングシステムは仮想メモリ管理システムを作動させ、それによって、カーネルは、データおよび命令を、必要なときにハードディスク４または外部メモリデバイスからＲＡＭ３へ移動させ、もはや必要でないときに戻すことができる。
利用可能な全メモリは、仮想メモリと呼ばれ、物理メモリのサイズを超えることができる。
仮想メモリ空間の一部は、物理メモリ内に対応するアドレスを有する。
仮想メモリ空間の残りは、ハードディスク４および／または外部メモリデバイス上のアドレスにマッピングされる。
以下では、特に指定のない限り、ハードディスクからＲＡＭへデータをロードすると言うときはいずれも、他の任意の外部メモリデバイスからＲＡＭへデータをロードすることも指すものと解釈されるべきである。
【００１１】
プログラムがコンパイルされるとき、コンパイラは、メモリ内のロケーションを表す、プログラムコードの仮想アドレスを生成する。
オペレーティングシステムが、その後、そのプログラムを実行している間に仮想アドレスにアクセスしようと試みるとき、システムは、特定のアドレスが物理アドレスに対応しているか否かをチェックする。
特定のアドレスが物理アドレスに対応している場合には、システムは、対応している物理アドレスのデータにアクセスする。
仮想アドレスが物理アドレスに対応していない場合には、システムは、ハードディスク４からデータを取り出し、そのデータを物理メモリ３に移動させる。
システムは、その後、通常の方法で物理メモリのデータにアクセスする。
物理メモリに十分に利用可能なメモリがない場合には、使用済みメモリを解放しなければならず、解放されるアドレスに保存されているデータおよび命令は、ハードディスク４へ移動される。
通例、物理メモリから移動されるデータは、しばらくの間使用されていないデータである。
【００１２】
ページは、仮想アドレスにマッピングすることができる物理メモリの最小単位である。
たとえば、ＨＰ−ＵＸ（商標）システムでは、ページサイズは４ＫＢである。
したがって、仮想ページは、仮想ページ番号ＶＰＮによって参照される一方、物理ページは、物理ページ番号ＰＰＮによって参照される。
必要な場合にのみ仮想メモリをメインメモリに移すプロセスは、デマンドページングと呼ばれる。
【００１３】
図３を参照すると、さまざまな種類のメモリとデータが記憶される場所とを管理するために、ＨＰ−ＵＸ（商標）等のオペレーティングシステムは、ページディレクトリ（ＰＤＩＲ）１６と呼ばれるテーブルをメモリに保持する。
ＰＤＩＲ１６は、現在メモリにあるすべてのページを経過監視する。
ページが或る仮想アドレス空間でマッピングされるとき、そのページには、ＰＤＩＲのエントリがアロケートされる。
ＰＤＩＲは、メモリの物理ページをその仮想アドレスにリンクする。
ＰＤＩＲ１６の全てのエントリは、物理ページ番号を有するフィールド１７、仮想ページ番号を有するフィールド１８、および、メモリのページに関する少なくとも１ビットの補助情報を有する少なくとも１つのフィールド１９を含む。
【００１４】
ＰＤＩＲ１６は、ＲＡＭ３に保存される。
システムを高速化するために、ＰＤＩＲのサブセットが、プロセッサ２のＴＬＢ１０に記憶される。
ＴＬＢは、仮想アドレスを物理アドレスに変換する。
したがって、各エントリは、仮想ページ番号および物理ページ番号の双方を含む。
【００１５】
本発明は、図３に示すハッシュページテーブルの配列の使用に限定されるものではなく、線形階層ページテーブル等の他のタイプのページテーブルを使用するシステムにも適用可能である。
【００１６】
図４を参照すると、ＣＰＵ８は、メモリページにアクセスしたいとき、最初に、ＶＰＮをインデックスとして使用してＴＬＢ１０を調べる。
ＰＰＮがＴＬＢ１０で見つかる場合、これはＴＬＢヒットと呼ばれ、プロセッサは、必要なページがメインメモリ３にあることを知る。
次に、ページからの必要なデータを、ＣＰＵ８によって使用されるキャッシュ９にロードすることができる。
キャッシュコントローラ（図示せず）は、必要なデータをキャッシュ９にロードするプロセスを制御することができる。
キャッシュコントローラは、必要なデータがキャッシュ９にすでに存在するか否かをチェックする。
必要なデータがキャッシュに存在しない場合には、キャッシュコントローラは、ＲＡＭからデータを取り出して、そのデータをキャッシュに移動させることができる。
キャッシュ９は、物理的にインデックスすることもできるし、仮想的にインデックスすることもできる。
【００１７】
ページ番号がＴＬＢで見つからない場合、これはＴＬＢミスと呼ばれ、必要なページがＰＤＩＲ１６に存在するか否かを調べるために、ＰＤＩＲ１６がチェックされる。
必要なページがＰＤＩＲ１６に存在する場合、これはＰＤＩＲヒットと呼ばれ、物理ページ番号が、ＴＬＢ１０にロードされ、ＣＰＵによってページにアクセスするための命令が再開される。
必要なページが存在しない場合、これは通常ＰＤＩＲミスと呼ばれ、これは、必要なページが物理メモリ３に存在せず、ハードディスク４または外部デバイスからメモリに必要なページを移す必要があることを示す。
ハードディスク４からメインメモリ３にページを移すプロセスは、当該技術分野で既知のように、ソフトウェアページフォールトハンドラ２０によって対処され、これによって、対応するＶＰＮ／ＰＰＮエントリがＰＤＩＲ１６およびＴＬＢ１０に作成される。
関連ページが物理メモリにロードされると、ＣＰＵによるアクセスルーチンが再開され、関連データをキャッシュにロードすることができ、ＣＰＵ８が使用することができる。
【００１８】
オペレーティングシステムのクラッシュ時に、物理メモリのデータをディスクに保存することによって、物理メモリのデータを後に解析でき、クラッシュの原因を特定することができるようにすることが多くの場合望ましい。
システムは、その後、再起動することができる。
クラッシュ時にデータをディスクに保存するプロセスを、以下では、クラッシュダンプと呼ぶ。
保存されたデータは、特定のプロセスのメモリイメージ、すなわちそのプロセスのアドレス空間の部分のメモリイメージをプロセッサレジスタの値等の他の情報と共に含むことができる。
クラッシュダンプは、カーネルのクラッシュダンプサブシステム１５で実行され、他のあらゆるアプリケーションと同様に、そのオペレーション用のメモリを必要とする。
このメモリは、物理メモリ３からアロケートしなければならない。
高性能クラッシュダンプアルゴリズムは、圧縮、並列Ｉ／Ｏ、暗号化、および、データをダンプするためのリモートストレージロケーションへのアクセスを含む。
高性能クラッシュダンプは、圧縮辞書、暗号化辞書、圧縮バッファ、および、Ｉ／Ｏバッファ用に大量のメモリを必要とする。
【００１９】
図５は、カーネル用の物理メモリ、クラッシュダンプ用の物理メモリ、および、ユーザプロセス用の物理メモリのアロケーションを示している。
少量のメモリが、起動時にカーネルによって確保される。
この量２１の一部は、カーネルテキスト、すなわちカーネルの必須プロセスを実行するための命令、および、初期データを含む。
カーネルテキストおよび初期データは、オペレーティングシステムがシャットダウンするまでメモリに存在しなければならず、ユーザプロセスに必要なページ用のスペースを空けるためにスワップアウトすることができない。
起動時に確保されたメモリの別の部分２２は、クラッシュダンプ用にアロケートされる。
起動時にカーネルによって確保されていないメモリ２３は、ランタイム中に仮想メモリページをマッピングするのに使用することができる。
カーネルは、物理メモリマップの形態でメモリのすべての利用可能な範囲の記録を保持する。
この物理メモリマップは、構造体のアレイであり、このアレイでは、各構造体は、メモリの利用可能な範囲の物理開始アドレスと、そのアドレスからの連続する、利用可能な物理ページの個数とを指定する。
このメモリの一部は、メモリが必要とされるときにカーネルプロセス用にアロケートされる。
その結果、カーネルデータ構造体のすべてが、連続するメモリアドレスに配置されることにはならない。
したがって、システムは、クラッシュ時に重要なカーネルデータ構造体を記憶するページのロケーションを容易に特定することができず、クラッシュダンプを実行するためにどのページを再利用してはいけないのかを容易に判断することができない。
【００２０】
起動時にクラッシュダンプ用にアロケートされるメモリ２２の量は、本発明によれば、実際のダンプを実行するのに必要なメモリよりもはるかに少なく、且つ、従来のダンプでアロケートされる量よりもはるかに少ない。
本発明によれば、ダンプに必要なメモリの大部分は、ランタイム中に他のプロセスが使用するのに利用可能なメモリから、クラッシュ後にアロケートされる。
以下では、クラッシュ時にメモリをアロケートするプロセスをより詳細に説明する。
【００２１】
図６を参照すると、起動時にクラッシュダンプ用にアロケートされるメモリ２２は、初期圧縮バッファ２４と、初期Ｉ／Ｏバッファ２５と、圧縮辞書、暗号化辞書、および、他の必要なデータを記憶するためのメモリエリア２６と、ダンプを実行するのに必要なデータ構造体を含むメモリロケーションのリストを記憶するためのアレイ２７とを含む。
このアレイは、以下では、クラッシュダンプメモリ使用リストと呼ぶ。
このリストは、図９に関して説明するように、クラッシュ時にポピュレートされる。
また、メモリ２２は、内部資源マップ２８と、特別なクラッシュダンプページフォールトハンドラ２９用の命令と、クラッシュダンプによって使用されるＩ／Ｏドライバ３０用の命令と、内部メモリアロケータ３１用の命令とを含む。
本発明が、ページング可能カーネルを有する装置で実施される場合、すなわち、カーネルデータおよびコードを要求に応じてページングすることができる装置で実施される場合、メモリ２２のデータ構造体の少なくとも一部を、起動時ではなくクラッシュ時に物理メモリにロードすることができることが理解されるべきである。
【００２２】
図７を参照すると、システムのクラッシュ時に、カーネルは、ダンプサブシステム１５に、２段階のクラッシュダンプを実行するように命令する。
最初に、ステップ７．１において、クラッシュダンプを正しく実行するためにダミークラッシュダンプが実行され、クラッシュダンプによって内部で使用されるページが特定される。
次に、ステップ７．２において、リアルダンプが、このダンプを実行するのに必要なページを含まないメモリ範囲からアロケートされたメモリを使用して実行される。
双方のダンプルーチンは、物理メモリマップをループするが、実際には、第２のダンプのみがメモリを不揮発性ストレージ５に保存する。
ダミークラッシュダンプは、図８および図９に関してより詳細に説明する。
リアルダンプは、図１０および図１１に関してより詳細に説明する。
【００２３】
図８を参照すると、ステップ８．１において、ダミークラッシュダンプルーチンは初期化される。
ダミークラッシュダンプルーチンは、不揮発性ディスク５に対するいかなる入力も出力も行われないように変更されたクラッシュダンプである。
ダミークラッシュダンプルーチンは、すべてのドライバＩ／Ｏルーチンを起動し、Ｉ／Ｏが行われないことを除いて、ダンプアルゴリズムを通じて完全に反復適用される。
また、ダミーダンプは、低メモリ動作モードで実行することもできる。
これは、ダンプ時間の削減、圧縮、暗号化等のダンプアルゴリズムによって提供される特別な改良を犠牲にして、はるかに小さなデータサイズが使用されることを意味する。
【００２４】
ステップ８．２において、カーネルページフォールトハンドラが、特定のクラッシュダンプページフォールトハンドラ２９と取り替えられる。
ステップ８．３において、補助情報を含むＰＤＩＲ１６のビット１９が、ＰＤＩＲ１６のすべての変換を無効としてマーキングするのに使用される。
ＴＬＢ１０も、ＰＤＩＲ１６の変更を反映するように更新される。
ステップ８．２およびステップ８．３の目的は、図９に関してより詳細に説明する。
【００２５】
ステップ８．４において、クラッシュダンプサブシステム１５は、物理メモリマップにリストされたページの第１のセットのページ番号を取り出す。
次に、ステップ８．５において、取り出されたページからのデータが圧縮バッファ２４に読み込まれ、ステップ８．６において、データが圧縮される。
ダンプ用にアロケートされたメモリが比較的小さいことを考慮すると、一時に圧縮されるページ数も小さくなければならない。
次に、ステップ８．７において、圧縮されたデータが、圧縮バッファから入出力バッファ２５にコピーされる。
ステップ８．８において、Ｉ／Ｏドライバ３０が起動されるが、入出力バッファのデータは、ディスク５に実際に書き込まれることは決してない。
たとえば、一実施形態では、Ｉ／Ｏドライバ３０は、当該技術分野で既知のように、ダイレクトメモリアクセス（ＤＭＡ）コントローラに、データを書き込むように命令することができる。
しかしながら、ダンプがダミーダンプであるときは、Ｉ／Ｏドライバ３０は、データを書き込むための命令をＤＭＡコントローラに渡すことは決してない。
【００２６】
次に、ステップ８．９において、カーネルサブシステム１５は、このルーチンが、物理メモリマップのすべてのページをループしたか否かをチェックする。
このルーチンが、すべてのページをループしていない場合には、物理メモリマップのすべてのページが処理されるまで、ステップ８．３〜８．９が繰り返される。
物理メモリマップのすべてのページが処理されると、このルーチンはステップ８．１０で終了する。
【００２７】
すべての物理メモリを必ずしもダンプしなければならないとは限らない。
たとえば、未使用のページ、ユーザプロセスページ、および、カーネルコードページは、デフォルトではダンプされない場合がある。
いくつかのオペレーティングシステムでは、クラッシュダンプサブシステム１５は、ユーザ設定をチェックして、ダンプに含まれるデータを特定することができる。
代替的には、物理メモリマップが、どのページをダンプすべきかの表示を含むことができる。
たとえば、システムは、各ページではなく、各メモリ範囲が何に使用されるのかを経過監視することができ、或るタイプのデータを含むか、または、あるプロセスに関連付けられるメモリ範囲のみをダンプに含めることができる。
図８のステップは、ダンプされるデータを含むページについてのみビジットされる。
【００２８】
ステップ８．１〜８．１０の全体を通じて、ダンプされるデータ以外のデータ構造体を含めて、クラッシュダンプデータ構造体および他のカーネルデータ構造体がアクセスされる。
ダミーダンプは、リアルダンプと同様のルーチンを起動するので、アクセスされるカーネルメモリおよびカーネルデータ構造体は、リアルダンプにも必要とされる。
したがって、カーネルメモリおよびカーネルデータ構造体を記憶するページは、リアルダンプを実行するためのメモリをアロケートするのに使用するには安全ではない。
ダンプされるデータは、物理メモリマップに記憶されている、そのデータに関連付けられる物理ページ番号を使用してアクセスされるのに対して、カーネルメモリおよびカーネルデータ構造体は、図３を参照して説明したように、それらに関連付けられる仮想ページ番号を使用してアクセスされる。
しかしながら、ＰＤＩＲ１６における物理ページ番号と仮想ページ番号との間の変換は、無効としてマーキングされているので、クラッシュダンプサブシステムを使用して、ページがそのページの仮想ページ番号を使用して最初にアクセスされるとき、特別なクラッシュダンプフォールトハンドラ２９が起動される。
このクラッシュダンプフォールトハンドラ２９は、変換がＴＬＢ１０において無効としてマーキングされていることが分かった場合も起動される。
【００２９】
より詳細には、図９を参照して、仮想ページ番号がダミークラッシュダンプルーチンによってアクセスされるごとに、ステップ９．１において、ＣＰＵはＴＬＢまたはＰＤＩＲにおいてＶＰＮを検索する。
ステップ９．２において、対応するＰＰＮが見つけられ、ステップ９．３において、ＰＤＩＲ１６の補助ビット１９またはＴＬＢの補助ビットが、変換が有効であるか否かを示すか否かがチェックされる。
変換が無効である場合、プロセスは、ステップ９．４に続き、クラッシュダンプフォールトハンドラ２９が起動される。
ステップ９．５において、特別なクラッシュダンプフォールトハンドラは、ＰＰＮがクラッシュダンプメモリ使用リスト２７に存在するか否かをチェックする。
物理ページ番号が含まれていない場合には、ステップ９．６において、物理ページ番号が保存され、次に、ステップ９．７において、ＰＤＩＲ１６の変換が有効としてマーキングされる。
次に、アドレスを変換するための命令が再開され、ステップ９．２において、ＣＰＵは物理ページ番号を見つけ、ステップ９．３において、変換が有効であることをチェックし、ステップ９．８において終了する。
【００３０】
ステップ９．５において、たとえば、仮想エイリアシングと呼ばれる、物理ページ番号が、同じ物理ページ番号にマッピングされた別の仮想ページ番号を通じてダミーダンプルーチンですでにアクセスされていたことから、その物理ページ番号がクラッシュダンプメモリ使用リスト２７にすでにあると判断された場合、プロセスは、ステップ９．７に直接続き、変換が有効としてマーキングされ、そのページにアクセスするための命令が再開される。
【００３１】
上述したように、ダンプされる実際の物理ページは、そのページの物理アドレスを使用してアクセスされ、変換は実行されない。
したがって、これらのアクセスは、ページフォールトにはならない。
代替的には、ページは、そのページの仮想ページ番号を使用してアクセスすることもできるが、補助ビット１９がチェックされないように、または、変換の無効フラグが無視されるように、メモリにアクセスするためのプロセスを変更することができる。
したがって、これらのページへのアクセスは、ページフォールトにならず、物理ページ番号は、リスト２９に記憶されない。
その結果、クラッシュダンプメモリ使用リスト２９は、ダンプのルーチンを実行するためにクラッシュダンプサブシステム１５によって使用されるページの物理ページ番号しか含まない。
クラッシュダンプページフォールトハンドラを起動することなくダンプされるページにアクセスする方法は、さまざまな既知の方法で実施することができ、本明細書では詳細に説明しない。
【００３２】
図１０を参照すると、次に、ステップ１０．１において、リアルダンプが初期化される。
ステップ１０．２において、カーネルページフォールトハンドラがリストアされる。
ステップ１０．３において、ＰＤＩＲテーブル１６に残っているすべての無効なエンティティが有効としてマーキングされる。
次に、ステップ１０．４において、当該技術分野で既知のように、ダンプを実行するメモリ要求が特定され、ステップ１０．５において、図１１に関してより詳細に説明するように、メモリをアロケートするために再利用することができるメモリ範囲が特定される。
【００３３】
再利用するのに安全なメモリ範囲にすでに記憶されているデータは、そのメモリを、クラッシュダンプサブシステム１５にアロケートすることができるようになる前にダンプしなければならない。
ステップ１０．６において、ダンプ用に再利用するのに安全なメモリ範囲のデータが、不揮発性ストレージ５に保存される。
このデータのダンプは、初期圧縮バッファ２４および初期Ｉ／Ｏバッファ２５を使用して行われる。
次に、クラッシュダンプサブシステム１５がそのデータのダンプを再び試みないように、ページが、物理メモリマップにダンプされたものとしてマーキングされる。
この時点で、メモリ範囲は、再利用されるように解放され、ステップ１０．７において、初期圧縮バッファおよび初期入出力バッファに取って代わるより大きな圧縮バッファおよび入出力バッファが、メモリ範囲からアロケートされる。
並列ダンプがカーネルによってサポートされている場合には、複数の入出力バッファを作成することができる。
加えて、マルチスレッド化された圧縮ダンプが、カーネルによってサポートされている場合には、複数の圧縮バッファを作成することができる。
【００３４】
次に、ステップ１０．８において、メインダンプが開始される。
このダンプは、ここでは、十分なメモリが利用可能であるので、通常モードで行うことができる。
ステップ１０．８において、ダンプされる物理メモリマップのページの次のセットが特定され、ステップ１０．９において、それらのページに含まれるデータが、新しくアロケートされた圧縮バッファに移動される。
次に、ステップ１０．１０において、データが圧縮され、ステップ１０．１１において入出力バッファにコピーされる。
ステップ１０．１２において、ドライバルーチン３０が起動される。
この時、ステップ１０．１３において、ドライバルーチンは、ＤＭＡコントローラに、Ｉ／Ｏバッファのデータを不揮発性クラッシュダンプディスク５に書き込むように命令する。
次に、ページは、物理メモリマップにダンプされたものとしてマーキングされる。
ステップ１０．１４において、ダンプされたものとしてマーキングされてないページが物理メモリマップに残っているか否かがチェックされる。
残っている場合には、物理メモリマップのすべてのページがダンプされるまで、残っているページについて、ステップ１０．８〜１０．１４が繰り返される。
すべてのページがダンプされると、ステップ１０．１５において、ダンプは終了する。
【００３５】
ここで、図１１に関してステップ１０．５をより詳細に説明する。
ステップ１１．１において、クラッシュダンプサブシステム１５が、内部クラッシュダンプメモリアロケータルーチン３１を起動する。
ステップ１１．２において、メモリアロケータは物理メモリマップにアクセスする。
図５に示すように、メモリの部分２１は、起動時にメモリにロードされるカーネルの静的データセグメントおよびテキストセグメントを含む。
メモリのこの部分のデータは、カーネルを実行するのに必要とされ、メモリの一部はクラッシュダンプを実行するのに再利用することができるが、この部分２１の再利用を回避することが最も安全である。
したがって、ステップ１１．３において、メモリアロケータは、メモリエリア２１において起動時にメモリにロードされるカーネルの静的データセグメントおよびテキストセグメントを通じて反復適用され、カーネルの静的データセグメントおよびテキストセグメントに使用される物理ページの最大値を特定し、ステップ１１．４において、メモリアロケータは、カーネルの静的データセグメントおよびテキストセグメントに使用される物理ページの最大値よりも上で、クラッシュダンプメモリ使用リスト２７内のいかなるページも含まない最も広いページ範囲を検索する。
次に、メモリアロケータは、特定された範囲を有するそれ自身の資源マップ２８を初期化する。
次に、図１０のステップ１０．６および１０．７に関して説明したように、特定された範囲のデータは、ダンプおよび再利用することができる。
【００３６】
図１１に関して説明したプロセスは、再利用するのに安全なメモリ範囲を特定するためのプロセスの単なる一例を構成するにすぎないことが理解されるべきである。
このプロセスの詳細は変更可能である。
たとえば、ステップ１１．３は、実行されない場合があり、カーネルの静的データセグメントおよびテキストセグメント用に確保されたメモリの部分２１を、クラッシュダンプルーチン用に再利用するのに安全なメモリ範囲を得るために検索することもできる。
【００３７】
一実施形態では、ダミークラッシュダンプルーチンおよびリアルクラッシュダンプルーチンは、ソフトウェアを使用して実施される。
カーネルは、ダンプがダミーダンプであるのか、または、リアルダンプであるのかを示す変数と、ダンプされるデータを特定するのに使用される資源マップを指し示す変数との２つの変数を取り入れるクラッシュダンプ関数をコールすることができる。
ダンプがダミーダンプであるのか、または、リアルダンプであるのかを示す変数の値に応じて、初期バッファがアクセスされるのか、または、クラッシュ時にアロケートされたバッファがアクセスされるのかが決定される。
この関数は、変数をドライバルーチンにも渡すことができる。
ドライバルーチンは、変数の値に基づいて、ＤＭＡコントローラに、ダンプされるデータを不揮発性ストレージに書き込むように命令するか否かを決定する。
実際のダンプ用のメモリは、Ｃの関数malloc()を使用してアロケートすることができる。
この関数malloc()は、当該技術分野において既知である。
一実施形態では、特別なcrashdump_malloc()関数を提供することができる。
この関数は、内部クラッシュダンプメモリ資源マップからメモリをアロケートするように記述することができる。
【００３８】
クラッシュダンプを実行するための、本発明の一実施形態によるアルゴリズムを以下に提供する。
【００３９】
Dumpsys(FakeDump, PhysicalMemoryMap[])
If (FakeDumpがTRUEである)
カーネルページフォールトハンドラをクラッシュダンプ固有のハンドラであるcrashdump_pagefault_handler()に取り替え、変換を無効としてマーキングする
Else
カーネルページフォールトハンドラをリストアし、変換を有効としてマーキングする
通常モード（すなわち、マルチスレッド化されたモード）で動作するためのクラッシュダンプ中のメモリ要求「MemReq」を特定する
「MemReq」に添ってアロケートするのに再利用することができるメモリ範囲を特定する。
メモリ資源マップcrashdump_malloc_rmap_init()を初期化する
初期バッファBFC_XおよびDRV_Xを使用して、再利用に特定されたメモリの範囲をディスクに保存（ダンプ）する
より大きなバッファ（並列ダンプ用の多くのインスタンス）をアロケートする
crashdump_malloc(BFC_Y)
crashdump_malloc(DRV_Y)
crashdump_rmap[]の範囲をダンプされたものとしてマーキングするか、または、PhysicalMemoryMap[]からそれらの範囲を除去する
DumpLoop:   すべてのデータがダンプされるまでPhysicalMemoryMap[]をループする
Begin
If (FakeDumpがTRUEである)
ダンプされるメモリエリアMA_Xを特定する
Else
ダンプされるメモリエリアMA_Yを特定する
If (FakeDumpがTRUEである)
ダンプされるメモリエリアMA_Xから圧縮バッファBFC_XにデータDA_Xを読み込む
Else
ダンプされるメモリエリアMA_Yから圧縮バッファBFC_YにデータDA_Yを読み込む
If (FakeDumpがTRUEである)
圧縮バッファBFC_Xを使用してデータを圧縮する
Else
圧縮バッファBFC_Yを使用してデータを圧縮する
If (FakeDumpがTRUEである)
圧縮されたデータをBFC_XからDRV_Xへコピーする
Else
圧縮されたデータをBFC_YからDRV_Yへコピーする
ドライバ書き込みルーチンを起動し、圧縮されたデータをディスクに書き込む：
If (FakeDumpがTRUEである)
DriverWrite(FakeWrite = TRUE, DRV_X)
Else
DriverWrite(FakeWrite = FALSE, DRV_Y)
If (すべての必要なデータがダンプされた)
Exit
Else
GoTo DumpLoop
End
【００４０】
上記アルゴリズムでは、DriverWrite()は、FakeWriteがFALSEであるときにのみＤＭＡを開始する。
【００４１】
一実施形態におけるページフォールトハンドラのアルゴリズムを以下に提供する。
【００４２】
crashdump_pagefault_handler()
プロセッサの特別なレジスタからフォールト仮想アドレス「fva」を取得する
フォールト仮想アドレス「fva」に対応する物理ページ「pfn」を取得する
If (pfnがcrashdump_memory_usage[]に存在しない)
「pfn」をcrashdump_memory_usage[]に保存する
【００４３】
メモリアロケータによって実行される関数のアルゴリズムを以下に提供する。
【００４４】
crashdump_malloc_rmap_init()
カーネルの静的データセグメント、テキストセグメントを通じて反復適用され、使用される物理ページの最大値kernel_static_phys_maxを特定する
カーネルの物理メモリマップを反復し、kernel_static_phys_maxよりも上で検索を開始して、crashdump_memory_usage[]に存在しない最も広いページ範囲を特定する
上記範囲を有する資源マップcrashdump_rmap[]を初期化する
crashdump_malloc()
crashdump_rmap[]からメモリをアロケートする
【００４５】
上記特定の実施形態に関して本発明を説明してきたが、変形が可能である。
【００４６】
たとえば、ＰＤＩＲ１６において補助情報を含むビット１９を無効としてマーキングする代わりに、ダンプに必要なカーネルデータ構造体を含むページを、他の或るページ保護メカニズムを使用してフォールトハンドラを起動することによってログ記録することができる。
たとえば、ページテーブルの無効／有効ビットの代わりに、メモリの特定のブロックに関連付けられる保護キーまたはタスク識別子を使用することができる。
たとえばPA-RISCTMプロセッサで使用される保護キーおよびタスク識別子は、当該技術分野で既知であるので、ここでは詳細に説明しない。
【００４７】
その上、いくつかのオペレーティングシステムでは、クラッシュダンプルーチンは、リアルモードで実行されることに留意すべきである。
換言すれば、いかなるアクセスチェックまたは保護チェックも行われない。
その場合、ＣＰＵがアクセスチェックおよび保護チェックを行うように、ダミーダンプは、仮想モードで実行することができ、実際のダンプは、フェールセーフオペレーションのリアルモードまたは物理モードで実行することができる。
【００４８】
加えて、メモリは、ページに分割される必要はない。
メモリの他のタイプのセグメンテーションも可能である。
【００４９】
本発明は、ダンプの目的で、システムクラッシュ後にメモリをアロケートするメカニズムを提供する。
その上、このメカニズムが必要とするメモリの記録保持（book keeping）は、従来技術よりも少ない。
その上、本発明によるメモリをアロケートするメカニズムを使用することによって、クラッシュダンプルーチンを開始するために起動中またはランタイム中に確保しなければならないメモリは、少量のみである。
その結果、装置は、従来技術よりも効率的にメモリを使用する。
【００５０】
ダミークラッシュダンプを実行するのに要する時間は、クラッシュダンププロセスが完了するのに要する時間を大幅に延ばさないことに留意すべきである。
その理由は、データを不揮発性ディスクに書き込む、多くの時間を要するタスクが、ダミークラッシュダンプルーチンでは行われないからである。
【００５１】
その上、クラッシュダンププロセスが完了するのに要する時間は、時に、ダミークラッシュダンプの一部としての圧縮または暗号化を行わないことによって、さらに削減することができる。
本発明によるクラッシュダンププロセスに要する時間は、ダミークラッシュダンプで使用されるより小さなデータサイズで実際のダンプが行われた場合よりも短い。
したがって、本発明によって、クラッシュダンプが完了するのに要する時間を大幅に延ばすことなくメモリのより効率的な使用が可能になる。
【００５２】
圧縮を含むようにクラッシュダンプアルゴリズムを説明してきたが、本発明は、圧縮が使用されないときにも利点を有する。
たとえば暗号化または並列Ｉ／Ｏを使用することから、かなりの量のメモリを使用するクラッシュダンプアルゴリズムを有するいかなるシステムも、ダンプを実行するのに必要なすべてのメモリが起動時にアロケートされる場合には、メモリの使用が非効率的になる。
本発明によれば、必要なメモリの大部分は、起動時ではなくクラッシュ時にアロケートすることができる。
ランタイム中に他のプロセスに使用されるメモリをクラッシュ時に再利用することができ、メモリはより効率的に使用される。
【図面の簡単な説明】
【００５３】
【図１】データ処理システムの概略図である。
【図２】ソフトウェアとハードウェアとの間の相互関係を示すコンピュータシステムの高レベルの概観を示す図である。
【図３】仮想メモリアドレスを物理メモリアドレスに変換するためのページディレクトリの構造を示す図である。
【図４】仮想メモリ管理システムにおいて仮想アドレスと物理アドレスとの間の変換に使用されるメカニズムを示す図である。
【図５】データ処理システムにおける物理メモリの一般的なパーティションを示す図である。
【図６】クラッシュダンプを実行するために最初にアロケートされたメモリの使用の概略図である。
【図７】本発明による２ステップクラッシュダンプを示すフローチャートである。
【図８】ダミークラッシュダンプルーチンを示すフローチャートである。
【図９】クラッシュダンプ用に再利用するのに安全でないメモリを特定するためのプロセスを示すフローチャートである。
【図１０】クラッシュダンプルーチンを実行するためのプロセスを示すフローチャートである。
【図１１】クラッシュダンプに再利用するのに安全なメモリ範囲を特定するためのプロセスを示すフローチャートである。
【符号の説明】
【００５４】
１・・・処理システム，
２・・・プロセッサ，
３・・・メインメモリ，
４・・・ハードディスク，
５・・・不揮発性ディスク
６・・・バス，
７・・・他のＩ／Ｏ，
９・・・キャッシュ，
１１・・・バスインターフェース，
１２・・・ハードウェア，
１３・・・カーネル，
１４・・・アプリケーションプログラム，
１５・・・クラッシュダンプサブシステム，
１９・・・補助情報，
２０・・・ページフォールトハンドラ，
２１・・・初期カーネルテキストおよび初期カーネルデータ，
２２・・・ダンプ用のメモリ，
２３・・・利用可能なメモリ，
２４・・・圧縮バッファ，
２５・・・Ｉ／Ｏバッファ，
２６・・・辞書等，
２７・・・クラッシュダンプメモリ使用リスト，
２８・・・資源マップ，
２９・・・ページフォールトハンドラ，
３０・・・Ｉ／Ｏドライバ，
３１・・・メモリアロケータ，
【図１】
2009032252.tif 000003
【図２】
2009032252.tif 000004
【図３】
2009032252.tif 000005
【図４】
2009032252.tif 000006
【図５】
2009032252.tif 000007
【図６】
2009032252.tif 000008
【図７】
2009032252.tif 000009
【図８】
2009032252.tif 000010
【図９】
2009032252.tif 000011
【図１０】
2009032252.tif 000012
【図１１】
2009032252.tif 000013
【外国語明細書】
Memory allocation for crash dump
Background of the Invention
Most operating systems have a procedure for saving the contents of the physical memory to non-volatile storage at the time of a crash to make it easier for engineers to later identify the cause of the crash. This procedure is normally carried out by a subsystem in the kernel. When the kernel crashes, for example as a result of a fatal error in one of the programs it is running, the crash dump routine reads the content of the physical memory and writes it to a stable storage like a dedicated internal disk or over a network to an external device.  Engineers can later run kernel debuggers on the stored data, the dump. 
Memory is required to run the crash dump. Conventionally, an area of the memory is allocated at boot-up of the system for this purpose. However, when the entire memory for running the crash is allocated at boot-up, the allocated memory cannot be used for other purposes during run-time. This results in an inefficient use of the memory resources available. The problem is made even worse in operating systems using more advanced crash dump routines which make use of compression, parallel input/output and dump via network because they have higher memory requirements and, therefore, even more memory is unavailable for other purposes during run-time. Additionally, the amount of memory required to perform the crash dump is, in some circumstances, easier to identify at the time of the crash than at boot-up.
There have been attempts to overcome the above problems. For example, the HP-UXTM operating system allocates the memory for performing the dump at the time of the crash and not at run-time. The technique used by this operating system to find memory to use at the time of crash involves keeping track of what type of data each page in memory stores. The kernel classifies each page in physical memory according to its usage and at crash time it can easily identify those pages that belong to a class of pages which is safe to reuse. A problem with this technique is that the records for keeping track of the class to which each page belongs take up a large portion of the available memory. 
Brief Description of the Drawings
Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:
Figure 1 is a schematic diagram of a data processing system;
Figure 2 is a high-level overview of a computer system illustrating the interrelationship between software and hardware;
Figure 3 illustrates the structure of a page directory for translating virtual memory addresses into physical memory addresses; 
Figure 4 illustrates a mechanism used to translate between virtual and physical addresses in a virtual memory management system;
Figure 5 illustrates a typical partition of physical memory in the data processing system;
Figure 6 is a schematic diagram of the uses of the memory initially allocated for performing a crash dump;
Figure 7 is a flowchart illustrating the two-step crash dump according to the invention;
Figure 8 is a flowchart illustrating a dummy crash dump routine;
Figure 9 is a flowchart illustrating a process for identifying memory that is not safe to be reused for the crash dump;
Figure 10 is a flowchart illustrating a process for performing a crash dump routine; and 
Figure 11 is a flowchart illustrating a process for identifying a memory range that is safe to be reused for the crash dump.  
Detailed Description of the Invention
Figure 1 is a schematic diagram of a processing system 1, such as a server or a workstation. It comprises a processor 2, a main memory 3, for example in the form of dynamic RAM, a hard disk 4 and an additional non-volatile disk 5, interconnected by a bus 6. The non-volatile disk 5 may be used for saving the physical data at the time of a crash.  The system typically also includes a variety of other input/output (I/O) subsystems 7 required for operation of the system, as would be apparent to a person skilled in the art.  The processor comprises a central processing unit CPU 8, an internal cache memory 9, a translation lookaside buffer TLB 10 and a bus interface module 11 for interfacing with the central bus 6. 
It should be understood that Figure 1 is exemplary only and the invention is not limited to systems with only a single processor. The invention may also be implemented in systems with a plurality of processors. Moreover, the non-volatile disk 5 may be connected to the I/O subsystem 7 instead of the central bus 6. The non-volatile disk 5 may, for example, be accessed over a network and located at a remote location. 
Figure 2 is a high-level overview of a computer system illustrating the interrelationship between software and hardware.  The system includes a hardware level 12, a kernel 13 and a user level 14.  The hardware level 12 includes the hardware system elements shown in Figure 1, the kernel 13 is the part of the operating system that controls the hardware and the user level 14 includes the application programs that are being run on the computer.  The processor runs one or more processes, which can be defined as programs in execution.  Processes in turn generally run as a number of threads, where a thread is an entity within a process that can be scheduled for execution by an operating system scheduler.  The kernel 13 also includes a crash dump subsystem 15 which will be described in more detail below.
The cache 9, main memory 3 and hard disk 4 shown in Figure 1 are all capable of storing program instructions and data, generally referred to together as data. The data can also be stored on external devices accessed through the I/O subsystems 7. One of the tasks of the kernel 13 is to manage the access to the memory resources. To execute a process or a thread, the data required for that process or thread must reside in the main memory 3, also referred to as physical memory, at the time of execution so that it is available to the CPU 8. Once the kernel 13 itself is loaded into memory at boot-up, it ensures that any other data required for running a desired process or thread is brought into physical memory 3. However, the amount of RAM is limited and if all the data associated with a particular program is made available in the RAM at the outset, 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 to move data and instructions from the hard disk 4 or external memory devices to RAM 3 when needed and move it back when not needed any longer. The total memory available is referred to as virtual memory and can 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 4 and/or external memory device. Hereinafter, any reference to loading data from the hard disk into RAM should also be construed to refer to loading data from any other external memory device into RAM, unless otherwise stated.
When a program is compiled, the compiler generates virtual addresses for the program code that represent locations in memory. When the operating system then tries to access the virtual addresses while running the program, 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 4 and moves the data into the physical memory 3. It then accesses the data in the physical memory in the normal way. If there is not enough available memory in the physical memory, used memory has to be freed and the data and instructions saved at the addresses to be freed is moved to the hard disk 4. Usually, the data that is moved from the physical memory is data that has not been used for a while.
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.
With reference to Figure 3, 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) 16 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. The PDIR links a physical page in memory to its virtual address. Every entry in the PDIR 16 contains a field 17 with the physical page number, a field 18 with the virtual page number and at least one field 19 with at least one bit of auxiliary information about the page of memory. 
The PDIR 16 is saved in RAM 3. To speed up the system, a subset of the PDIR is stored in the TLB 10 in the processor 2.  The TLB translates virtual to physical addresses. Therefore, each entry contains both the virtual page number and the physical page number.  
The invention is not restricted to use of the hashed page table arrangement shown in Figure 3, but is applicable to systems using other types of page table, such as a linear hierarchical page table.  
With reference to Figure 4, when the CPU 8 wishes to access a memory page, it first looks in the TLB 10 using the VPN as an index.  If a PPN is found in the TLB 10, which is referred to as a TLB hit, the processor knows that the required page is in the main memory 3.  The required data from the page can then be loaded into the cache 9 to be used by the CPU 8. A cache controller (not shown) may control the process of loading the required data into the cache 9. The cache controller will check whether the required data already exists in the cache 9. If not, the cache controller can retrieve the data from the RAM and move it into the cache. The cache 9 may be either physically or virtually indexed.
If the page number is not found in the TLB, which is referred to as a TLB miss, the PDIR 16 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 10 and the instruction to access the page by the CPU 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 3, and needs to be brought into memory from the hard disk 4 or from an external device.  The process of bringing a page from the hard disk 4 into the main memory 3 is dealt with by a software page fault handler 20 and causes corresponding VPN/PPN entries to be made in the PDIR 16 and TLB 10, as is well known in the art. When the relevant page has been loaded into physical memory, the access routine by the CPU is restarted and the relevant data can be loaded into the cache and used by the CPU 8.
When the operating system crashes, it is often desirable to save the data in the physical memory to a disk such that it can be analysed later and the cause of the crash can be identified. The system can then be restarted. The process of saving data to disk at the time of crash will hereinafter be referred to as a crash dump. The data saved may include the memory image of a particular process, the memory image of parts of the address space of that process along with other information such as the values of the processor registers. The crash dump is performed in the crash dump subsystem 15 of the kernel and like any other application requires memory for its operations. This memory has to be allocated from the physical memory 3. High performance crash dump algorithms include compression, parallel I/O, encryption and access to remote storage locations for dumping the data. High performance crash dumps require a large amount of memory for the compression and encryption dictionaries, compression buffers and I/O buffers. 
Figure 5 illustrates the allocation of physical memory for the kernel, for the crash dump and for user processes. A small amount of memory is reserved by the kernel at boot-up. A portion of this amount 21 includes kernel text, i.e. instructions for carrying out essential processes of the kernel, and initial data. The kernel text and initial data must reside in memory until the operating system shuts down and cannot be swapped out to make room for pages required for user processes. Another portion 22 of the memory reserved at boot-up is allocated for the crash dump. The memory 23 that is not reserved by the kernel at boot-up can be used for mapping virtual memory pages during run-time. The kernel keeps a record of all the available ranges of memory in the form of a physical memory map. The physical memory map is an array of structures in which each structure specifies a physical starting address of an available range of memory and the number of contiguous physical pages from that address that are available. Some of this memory will be allocated for kernel processes as and when the memory is needed. Consequently, the kernel data structures are not all located at consecutive memory addresses. As such, the system cannot easily identify the location of pages that store important kernel data structures at crash time and determine which pages must not be reused for performing the crash dump.  
The amount of memory 22 allocated at boot-up for the crash dump, according to the invention, is much smaller than the memory required to run the actual dump and much smaller than the amount that would be allocated in a conventional dump. According to the invention, a large proportion of the memory required for the dump is allocated after the crash from memory available to be used by other processes during run-time. The process for allocating memory at the time of the crash will be described in more detail below. 
With reference to Figure 6, the memory 22 allocated for the crash dump at boot-up includes an initial compression buffer 24, an initial I/0 buffer 25, a memory area 26 for storing the compression dictionaries, encryption dictionaries and other necessary data and an array 27 for storing a list of memory locations comprising data structures that are required for performing the dump. This array will be referred to as the crash dump memory usage list hereinafter. The list is populated at crash time as will be described with respect to Figure 9.  The memory 22 also comprises an internal resource map 28, instructions for a special crash dump page fault handler 29, instructions for I/O drivers 30 used by the crash dump and instructions for an internal memory allocator 31. It should be understood that if the invention is implemented in an apparatus with a pageable kernel, i.e. in which kernel data and code can be paged on demand, at least some of the data structures of memory 22 can be loaded into physical memory at the time of the crash, rather than at boot-up. 
With reference to Figure 7, when the system crashes the kernel instructs the dump subsystem 15 to perform a two-stage crash dump. First, a dummy crash dump is run at step 7.1 to identify the pages that are used internally by the crash dump for its correct running, then the real dump is run at step 7.2 using memory allocated from memory ranges that do not include the pages that are required to perform the dump. Both dump routines loop through the physical memory map but only the second one actually saves the memory to non-volatile storage 5. The dummy crash dump will be described in more detail with respect to Figures 8 and 9 and the real dump will be described in more detail with respect to Figures 10 and 11.
With reference to Figure 8, the dummy crash dump routine is initialised at step 8.1. A dummy crash dump routine is a crash dump modified such that no input or output to the non-volatile disk 5 is performed. It invokes all the driver I/O routines and iterates through the dump algorithm fully except that the I/O is not performed. The dummy dump may also be run in a low memory operating mode, which means that much smaller data sizes are used at the cost of the special improvements provided by the dump algorithm, such as reduced dump time, compression and encryption. 
At step 8.2, the kernel page fault handler is replaced with the specific crash dump page fault handler 29. At step 8.3, the bits 19 of the PDIR 16 containing auxiliary information are used to mark all translations in the PDIR 16 as invalid.  The TLB 10 is also updated to reflect the changes in the PDIR 16.  The purpose of steps 8.2 and 8.3 will be described in more detail with respect to Figure 9. 
At step 8.4, the crash dump subsystem 15 retrieves the page numbers of the first set of pages listed in the physical memory map. At step 8.5, data from the retrieved pages is then read into the compression buffer 24 and at step 8.6, the data is compressed. Considering that the memory allocated for the dump is relatively small, the number of pages compressed at a time must also be small. At step 8.7, the compressed data is then copied from the compression buffer to the input/output buffer 25. At step 8.8, the I/O drivers 30 are invoked but the data in the input/output buffers is never actually written to disk 5. For example, in one embodiment, the I/O drivers 30 may instruct a Direct Memory Access (DMA) controller to write the data as is well known in the art. However, when the dump is a dummy dump, the I/O drivers 30 never pass the instruction to the DMA controller to write the data. 
At step 8.9, the kernel subsystem 15 then checks if the routine has looped through all the pages in the physical memory map. If not, steps 8.3 to 8.9 are repeated until all the pages in the physical memory map have been processed. When all the pages in the physical memory map have been processed, the routine exits at step 8.10. 
Not all the physical memory must necessarily be dumped. For example, unused pages, user process pages and kernel code pages may not be dumped by default. In some operating systems, the crash dump subsystem 15 may check user settings to identify the data to be included in the dump. Alternatively, the physical memory map may include an indication of which pages should be dumped. For example, the system may keep track of what each memory range, rather than each page, is used for and only the memory ranges that include data of certain types or associated with certain processes may be included in the dump. The steps of Figure 8 are only visited for the pages that contain data to be dumped. 
Throughout steps 8.1 to 8.10, crash dump data structures and other kernel data structures are accessed, including data structures apart from the data to be dumped.  Since the dummy dump invokes similar routines to the real dump, the accessed kernel memory and data structures are also required for the real dump. Therefore, the pages storing the kernel memory and data structures are not safe to be used for allocating memory for running the real dump. Whereas the data to be dumped is accessed using its associated physical page numbers stored in the physical memory map, the kernel memory and data structures are accessed using their associated virtual page numbers as explained with reference to Figure 3. However, since the translations between the physical page numbers and the virtual page numbers in the PDIR 16 have been marked as invalid, the first time a page is accessed using its virtual page number using the crash dump subsystem, the special crash dump fault handler 29 is invoked. The crash dump fault handler 29 is also invoked if a translation is found to be marked as invalid in the TLB 10.
In more detail, with reference to Figure 9, each time a virtual page number is accessed by the dummy crash dump routine, the CPU searches for the VPN in the TLB or in the PDIR at step 9.1. The corresponding PPN is found at step 9.2 and at step 9.3 it is checked whether the auxiliary bit 19 in the PDIR 16, or an auxiliary bit in the TLB, indicates whether the translation is valid. If the translation is invalid, the process continues to step 9.4 and the crash dump fault handler 29 is invoked. The special crash dump fault handler checks whether the PPN is present in the crash dump memory usage list 27 at step 9.5. If the physical page number is not included, the physical page number is saved at step 9.6 and the translation in the PDIR 16 is then marked as valid at step 9.7. The instruction to translate the address is then restarted, the CPU finds the physical page number at step 9.2, checks that the translation is valid at step 9.3 and exits at step 9.8. 
If at step 9.5, it is determined that the physical page number is already in the crash dump memory usage list 27, for example because it has already been accessed in the dummy dump routine through another virtual page number mapping onto the same physical page number, referred to as virtual aliasing, the process continues directly to step 9.7, the translation is marked as valid and the instruction to access the page is restarted.
As mentioned above, the actual physical pages to be dumped are accessed using their physical addresses and no translations are carried out. Therefore these accesses do not result in page faults. Alternatively, the pages may be accessed using their virtual page numbers but the process for accessing the memory may be modified such that the auxiliary bits 19 are not checked or the invalid flags of the translations are ignored. Therefore, the access to these pages does not result in page faults and the physical page numbers are not stored in the list 29. Consequently, the crash dump memory usage list 29 only includes the physical page numbers of pages used by the crash dump subsystem 15 to perform the routines of the dump. A method of accessing the pages to be dumped without invoking the crash dump page fault handler can be implemented in various known ways and will not be described in detail herein.
With reference to Figure 10, the real dump is then initialised at step 10.1. At step 10.2, the kernel page fault handler is restored. At step 10.3, all remaining invalid entries in the PDIR table 16 are marked as valid.  The memory needs for running the dump are then identified as well known in the art at step 10.4 and the memory ranges that can be reused for allocating memory are identified at step 10.5 as will be described in more detail with respect to Figure 11. 
The data already stored in the memory range that is safe to reuse must be dumped before the memory can be allocated to the crash dump subsystem 15. At step 10.6, the data in the memory range that is safe to be reused for the dump is saved to non-volatile storage 5. The dump of the data is performed using the initial compression buffer 24 and the initial I/O buffer 25. The pages are then marked as dumped in the physical memory map such that the crash dump subsystem 15 does not attempt to dump the data again. The memory range is now free to be reused and at step 10.7, larger compression and input/output buffers to replace the initial compression and input/output buffers are allocated from the memory range.  If parallel dumps are supported by the kernel, a plurality of input/output buffers may be created.  Additionally, if multithreaded compressed dumps are supported by the kernel, a plurality of compression buffers may be created. 
The main dump is then started at step 10.8. The dump can now be performed in normal mode because enough memory is available. The next set of pages in the physical memory map to be dumped is identified at step 10.8 and at step 10.9 the data contained in the pages is moved to the newly allocated compression buffer. The data is then compressed at step 10.10 and copied to the input/output buffer at step 10.11. At step 10.12 the driver routines 30 are invoked. This time, the driver routines instruct the DMA controller at step 10.13 to write the data in the I/O buffers to the non-volatile crash dump disk 5. The pages are then marked as dumped in the physical memory map. At step 10.14 it is checked whether there are any remaining pages in the physical memory map that are not marked as dumped. If there are, steps 10.8 to 10.14 are repeated for the remaining pages until all the pages in the physical memory map have been dumped. When all the pages have been dumped, the dump exits at step 10.15. 
Step 10.5 will now be described in more detail with respect to Figure 11. At step 11.1, the crash dump subsystem 15 invokes the internal crash dump memory allocator routines 31. The memory allocator accesses the physical memory map at step 11.2. As shown in Figure 5, a portion 21 of the memory comprises kernel static data and text segments that are loaded into the memory at boot up. The data in this portion of the memory is required for the kernel to run and although some of the memory could be reused for running the crash dump it is safest to avoid reusing it.  Therefore, at step 11.3, the memory allocator iterates through the kernel static data and text segments that are loaded into memory at boot up in memory area 21 and identifies the highest physical page used for kernel static data and text segments and, at step 11.4, the memory allocator searches above the highest physical page used for kernel static data and text segments for the largest range of pages that does not include any pages in the crash dump memory usage list 27. The memory allocator then initialises its own resource map 28 with the identified range. The data in the identified range can then be dumped and reused as described with respect to steps 10.6 and 10.7 in Figure 10. 
It should be understood that the process described with respect to Figure 11 constitutes just one example of a process for identifying a memory range that is safe to be reused. The details of this process can be varied. For example, step 11.3 may not be performed and the portion of memory 21 reserved for kernel static data and text segments may also be searched for a memory range that is safe to reuse for the crash dump routine.
In one embodiment, the dummy crash dump routine and the real crash dump routine are implemented using software. The kernel may call a crash dump function that takes two variables, a variable indicating whether the dump is a dummy dump or a real dump and a variable pointing to the resource map used for identifying data to be dumped. Whether the initial buffers or the buffers allocated at crash time are accessed is determined in dependence on the value of the variable indicating whether the dump is a dummy dump or a real dump.  The function may also pass the variable to the driver routines which in turn determines based on the value of the variable whether to instruct the DMA controller to write the data to be dumped to non-volatile storage or not.  The memory for the actual dump may be allocated using the C function malloc(), which is well known in the art. In one embodiment, a special crashdump_malloc() function may be provided. This function may be written to allocate memory from the internal crash dump memory resource map. 
An algorithm, according to one embodiment of the invention, for performing the crash dumps is provided below:
Dumpsys(FakeDump, PhysicalMemoryMap[])
If (FakeDump is TRUE)
Replace Kernel Page Fault handler with crash dump specific  
handler, crashdump_pagefault_handler() and mark 
translations as invalid
Else
Restore Kernel Page Fault handler and mark translations as 
valid
Identify memory needs during crash dump, "MemReq", for  
operating in normal mode (i.e multi-threaded mode)
Identify memory ranges that can be reused for allocating upto 
"MemReq".  Initialize the memory resource map 
crashdump_malloc_rmap_init()
Save (dump) ranges of memory identified for reuse to the disk 
using initial buffers BFC_X and DRV_X. 
Allocate bigger buffers (many instances for a parallel dump)
crashdump_malloc(BFC_Y)
crashdump_malloc(DRV_Y)
Mark ranges in crashdump_rmap[] as dumped or remove 
them from the PhysicalMemoryMap[].
DumpLoop:    Loop PhysicalMemoryMap[] Until All Data is Dumped
Begin
If (FakeDump is TRUE)
Identify memory area MA_X to be dumped
Else
Identify memory area MA_Y to be dumped
If (FakeDump is TRUE)
Read data, DA_X, from memory area MA_X to be 
dumped into compression buffer BFC_X
Else
Read data, DA_Y, from memory area MA_Y to be 
dumped into compression buffer BFC_Y
If (FakeDump is TRUE)
compress data using compression buffer BFC_X
Else
compress data using compression buffer BFC_Y
If (FakeDump is TRUE)
Copy compressed data from BFC_X to DRV_X
Else
Copy compressed data from BFC_Y to DRV_Y
Invoke driver write routine and write compressed data to disk: 
If (FakeDump is TRUE)
DriverWrite(FakeWrite = TRUE, DRV_X)
Else
DriverWrite(FakeWrite = FALSE, DRV_Y)
If (all required data is dumped)
Exit
Else
GoTo DumpLoop
End
In the above algorithm, DriverWrite() starts DMA only when FakeWrite is FALSE.
The algorithm for the Page Fault Handler, in one embodiment, is provided below:
crashdump_pagefault_handler()
Get Fault Virtual Address, "fva", from processor special registers
Get Physical page, "pfn", corresponding to Fault Virtual Address, 
"fva"
If (pfn not present in crashdump_memory_usage[])
save "pfn" in crashdump_memory_usage[]
The algorithms for the functions carried out by the memory allocator is provided below:
crashdump_malloc_rmap_init()
Iterate thru Kernel static data, text segments and identify highest 
physical page used, kernel_static_phys_max.
Iterate physical memory map of kernel, and start search above
kernel_static_phys_max to identify biggest range of pages, which 
are not present in crashdump_memory_usage[].
Initialize resource map crashdump_rmap[] with above ranges
crashdump_malloc()
Allocate memory from crashdump_rmap[].
Although the invention has been described with respect to a specific embodiment above, variations are possible. 
For example, instead of marking the bit 19 comprising auxiliary information in the PDIR 16 as invalid, the pages that contain kernel data structures required for the dump can be logged by using some other page protection mechanism to invoke the fault handler. For example, protection keys or task identifiers associated with a particular block of memory may be used instead of the invalid/valid bit in the page table. Protection keys and task identifiers, used for example in PA-RISCTM processors, will not be described in detail here since they are known in the art. 
Moreover, it should be noted that in some operating systems the crash dump routine is run in real mode. In other words, no access or protection checks are performed. In that case, the dummy dump may be run in virtual mode such that the CPU performs access and protection checks and the actual dump may be run in real mode or physical mode for fail safe operation. 
Additionally, the memory does not have to be divided into pages. Other types of segmentations of memory are also possible. 
The invention provides a mechanism to allocate memory after system crash for dump purposes. Moreover, the mechanism requires less book keeping of memory than in the prior art.  Moreover, by using the mechanism for allocating memory according to the invention, only a small amount of memory must be reserved during boot-up or run-time for initiating the crash dump routine. As a result, the apparatus uses memory more efficiently than in the prior art.
It should be noted that the time taken for the dummy crash dump to run does not extend the time taken for the crash dump process to complete significantly, because the time-consuming task of writing the data to non-volatile disk is not performed in the dummy crash dump routine. 
Moreover, the time taken for the crash dump process to complete can sometimes be reduced further by not performing any compression or encryption as part of the dummy crash dump. The time taken for the crash dump process according to the invention is shorter than if the actual dump was performed with the smaller data sizes used in the dummy crash dump.  Therefore, the invention allows more efficient use of memory without extending the time taken for the crash dump to complete significantly.
Although the crash dump algorithm has been described to include compression, the invention also has advantages when compression is not used. Any system with a crash dump algorithm that uses a significant amount of memory because it employs, for example, encryption or parallel I/O would provide inefficient use of memory if all the memory required for performing the dump is allocated at boot-up. According to the invention, a large proportion of the required memory can be allocated at the time of the crash instead. Memory used during run time for other processes can be reused at the time of the crash and memory is used more efficiently.
Claims
1.     A method of performing a crash dump of memory in a data processing apparatus, the method comprising:
running a first routine to identify memory locations of data for use by a second routine;
allocating memory for performing the second routine from a memory range that does not contain the identified memory locations; and
running the second routine using the allocated memory, wherein the first routine comprises a dummy crash dump routine and the second routine comprises a crash dump routine.
2.    A method according to claim 1, wherein the dummy crash dump routine uses smaller data sizes than the crash dump routine.
3.    A method according to claim 1, wherein the running of the dummy crash dump routine is triggered by a kernel crash.
4.    A method according to claim 1, wherein the data processing apparatus comprises a virtual memory management system and wherein running a dummy crash dump routine to identify the memory locations of data comprises creating a record of physical page addresses corresponding to virtual page addresses accessed by the dummy crash dump routine. 
5.    A method according to claim 4, wherein running a dummy crash dump routine further comprises invoking a crash dump page fault handler when a virtual page address is accessed by the dummy crash dump routine and wherein saving the physical page addresses corresponding to the virtual page addresses is carried out by the crash dump page fault handler.
6.    A method according to claim 5, further comprising marking all translations in a page table of the apparatus as invalid to invoke the crash dump page fault handler during the dummy crash dump routine. 
7.     A method according to claim 1, further comprising:
identifying a memory range that does not contain the identified memory locations; and
saving data in the memory range to non-volatile storage before allocating memory therefrom for performing the crash dump routine.
8.    A method according to claim 1, wherein allocating memory for performing a crash dump routine comprises allocating memory for at least one compression buffer.
9.    A method according to claim 1, wherein allocating memory for performing a crash dump routine comprises allocating a plurality of buffers for performing parallel I/O.
10.    A method according to claim 1, wherein running the crash dump routine comprises running at least one out of compression algorithms, parallel I/O operation algorithms, encryption algorithms and algorithms to write to non-volatile storage over a network.
11.    A module for performing a crash dump of memory in a data processing apparatus, comprising
a processing unit for running a first routine to identify memory locations of data for use by a second routine; and
a memory allocator for allocating memory for the second routine from a memory range that does not contain the identified memory locations, 
said processing unit being further operable to run the second routine using the memory allocated by the memory allocator, wherein the first routine comprises a dummy crash dump routine and the second routine comprises a crash dump routine.
12.    A module according to claim 11, wherein the processing unit is configured to run the dummy crash dump routine in a low memory operating mode.
13.    A module according to claim 11, wherein the processing unit is operable to access memory of the data processing apparatus using virtual memory addresses and the module further comprises an internal memory for saving physical addresses corresponding to virtual addresses accessed during the dummy crash dump routine.
14.    A module according to claim 11, further comprising a page fault handler, wherein the page fault handler is operable to save said physical addresses corresponding to virtual addresses accessed during the dummy crash dump routine.
15.    A module according to claim 14, wherein said processing unit is operable to mark all translations in a page table of the data processing apparatus as invalid to invoke the crash dump page fault handler during the dummy crash dump routine. 
16.     A module according to claim 11, wherein the memory allocator is operable to identifying a memory range that does not contain the identified memory locations; and
said processing unit is operable to save the data in the memory range to non-volatile storage before allocating memory therefrom for performing the actual dump.
17.    A module according to claim 11, constituting a kernel.
18.    An apparatus comprising
a memory;
a kernel; 
a memory allocator for allocating a first portion of said memory to be used for a crash dump of a second portion of said memory when the kernel crashes; and
a crash dump module for saving said second portion of the memory to non-volatile storage when the kernel crashes, 
the crash dump module further being operable to run a dummy crash dump routine when the kernel crashes to identify kernel data structures used to perform a crash dump routine and the memory allocator being configured to identify a memory range that does not include the identified kernel data structures and to allocate said first portion of said memory to be used for the crash dump from the identified memory range.
Abstract
Memory allocation for crash dump
A method and module for performing a crash dump in a data processing apparatus in which memory for running the crash dump routine is allocated at the time of the crash. The method comprises running a first routine to identify memory locations of data for use by a second routine; allocating memory for performing the second routine from a memory range that does not contain the identified memory locations; and running the second routine using the allocated memory, wherein the first routine comprises a dummy crash dump routine and the second routine comprises a crash dump routine. The dummy crash dump may use smaller data sizes and does not perform any input or output to non-volatile storage of the data to be dumped. When a memory range that is safe to be reused has been identified, the data stored therein can be dumped and then memory for performing the actual crash dump routine can be allocated from the memory range and be reused for performing the actual crash dump routine. 
(Figure 7)
2009032252.tif 000014
2009032252.tif 000015
2009032252.tif 000016
2009032252.tif 000017
2009032252.tif 000018
2009032252.tif 000019
2009032252.tif 000020
2009032252.tif 000021
2009032252.tif 000022
2009032252.tif 000023
2009032252.tif 000024