JP5255348B2 - クラッシュダンプ用のメモリアロケーション - Google Patents
クラッシュダンプ用のメモリアロケーション Download PDFInfo
- Publication number
- JP5255348B2 JP5255348B2 JP2008176598A JP2008176598A JP5255348B2 JP 5255348 B2 JP5255348 B2 JP 5255348B2 JP 2008176598 A JP2008176598 A JP 2008176598A JP 2008176598 A JP2008176598 A JP 2008176598A JP 5255348 B2 JP5255348 B2 JP 5255348B2
- Authority
- JP
- Japan
- Prior art keywords
- memory
- routine
- crash dump
- data
- crash
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/10—Address translation
- G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
- G06F12/1045—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] associated with a data cache
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0778—Dumping, i.e. gathering error/state information after a fault for later diagnosis
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Debugging And Monitoring (AREA)
Description
本発明は、クラッシュダンプルーチンを実行するメモリがクラッシュ時にアロケートされるデータ処理装置においてクラッシュダンプを実行できるようにする方法およびその装置に関する。
ほとんどのオペレーティングシステムは、エンジニアが後にクラッシュの原因を特定することをより容易にするために、クラッシュ時に物理メモリのコンテンツを不揮発性ストレージに保存するためのプロシージャを有する。
このプロシージャは、通常、カーネルのサブシステムによって実行される。
たとえば、カーネルが実行しているプログラムの１つにおける致命的エラーの結果として、カーネルのクラッシュ時に、クラッシュダンプルーチンは、物理メモリのコンテンツを読み出し、そのコンテンツを、専用内部ディスクのような安定したストレージに書き込むか、または、ネットワークを介して外部デバイスに書き込む。
エンジニアは、後に、記憶されたデータであるダンプに対してカーネルデバッガを実行することができる。
このプロシージャは、通常、カーネルのサブシステムによって実行される。
たとえば、カーネルが実行しているプログラムの１つにおける致命的エラーの結果として、カーネルのクラッシュ時に、クラッシュダンプルーチンは、物理メモリのコンテンツを読み出し、そのコンテンツを、専用内部ディスクのような安定したストレージに書き込むか、または、ネットワークを介して外部デバイスに書き込む。
エンジニアは、後に、記憶されたデータであるダンプに対してカーネルデバッガを実行することができる。
クラッシュダンプを実行するためには、メモリが必要である。
従来では、メモリの或るエリアが、この目的のためにシステムの起動時にアロケートされる。
しかしながら、クラッシュを実行するためのメモリ全体が起動時にアロケートされると、アロケートされたメモリは、ランタイム中に他の目的に使用することができない。
この結果、利用可能なメモリ資源の使用は非効率的なものとなる。
この問題は、圧縮、並列入出力、および、ネットワークを介したダンプを利用する、より高度化されたクラッシュダンプルーチンを使用するオペレーティングシステムではさらに悪化する。
その理由は、それらのオペレーティングシステムは、より高いメモリ要件を有し、したがって、さらに多くのメモリがランタイム中に他の目的で利用不能となるからである。
加えて、クラッシュダンプを実行するのに必要なメモリ量の特定は、いくつかの状況では、起動時よりもクラッシュ時の方が容易である。
従来では、メモリの或るエリアが、この目的のためにシステムの起動時にアロケートされる。
しかしながら、クラッシュを実行するためのメモリ全体が起動時にアロケートされると、アロケートされたメモリは、ランタイム中に他の目的に使用することができない。
この結果、利用可能なメモリ資源の使用は非効率的なものとなる。
この問題は、圧縮、並列入出力、および、ネットワークを介したダンプを利用する、より高度化されたクラッシュダンプルーチンを使用するオペレーティングシステムではさらに悪化する。
その理由は、それらのオペレーティングシステムは、より高いメモリ要件を有し、したがって、さらに多くのメモリがランタイム中に他の目的で利用不能となるからである。
加えて、クラッシュダンプを実行するのに必要なメモリ量の特定は、いくつかの状況では、起動時よりもクラッシュ時の方が容易である。
上記問題を克服する試みが行われてきた。
たとえば、ＨＰ−ＵＸＴＭオペレーティングシステムは、ランタイム時ではなくクラッシュ時にダンプを実行するためのメモリをアロケートする。
クラッシュ時に使用するメモリを見つけるためにこのオペレーティングシステムによって使用される技法は、メモリの各ページがどのようなタイプのデータを記憶するのかを経過監視することを伴う。
カーネルは、物理メモリの各ページをその使用に従って分類し、クラッシュ時には、再利用するのに安全であるページのクラスに属するページを容易に特定することができる。
この技法に関する問題は、各ページが属するクラスを経過監視するための記録が、利用可能なメモリの大きな部分を占めるということである。
たとえば、ＨＰ−ＵＸＴＭオペレーティングシステムは、ランタイム時ではなくクラッシュ時にダンプを実行するためのメモリをアロケートする。
クラッシュ時に使用するメモリを見つけるためにこのオペレーティングシステムによって使用される技法は、メモリの各ページがどのようなタイプのデータを記憶するのかを経過監視することを伴う。
カーネルは、物理メモリの各ページをその使用に従って分類し、クラッシュ時には、再利用するのに安全であるページのクラスに属するページを容易に特定することができる。
この技法に関する問題は、各ページが属するクラスを経過監視するための記録が、利用可能なメモリの大きな部分を占めるということである。
本願にかかる方法は、上述した背景からなされ、データ処理装置においてメモリのクラッシュダンプを実行する方法であって、第２のルーチンによって使用されるデータのメモリロケーションを特定する第１のルーチンを実行することと、前記特定されたメモリロケーションを含まないメモリ範囲から前記第２のルーチンの実行用メモリをアロケートすることと、前記アロケートされたメモリを使用して前記第２のルーチンを実行することと、を含み、前記第１のルーチンは、ダミークラッシュダンプルーチンを含み、前記第２のルーチンは、クラッシュダンプルーチンを含む。
次に、添付図面を参照して、本発明の実施形態を例として説明する。
図１は、サーバまたはワークステーション等の処理システム１の概略図である。
この処理システム１は、プロセッサ２、たとえばダイナミックＲＡＭの形態のメインメモリ３、ハードディスク４、および、追加の不揮発性ディスク５を備える。
これらは、バス６によって相互接続されている。
不揮発性ディスク５は、クラッシュ時に物理データを保存するのに使用することができる。
システムは、当業者に明らかなように、通常、システムのオペレーションに必要な他のさまざまな入出力（Ｉ／Ｏ）サブシステム７も含む。
プロセッサは、中央処理装置ＣＰＵ８、内部キャッシュメモリ９、変換索引バッファＴＬＢ１０、および、中央バス６とインターフェースするためのバスインターフェースモジュール１１を備える。
この処理システム１は、プロセッサ２、たとえばダイナミックＲＡＭの形態のメインメモリ３、ハードディスク４、および、追加の不揮発性ディスク５を備える。
これらは、バス６によって相互接続されている。
不揮発性ディスク５は、クラッシュ時に物理データを保存するのに使用することができる。
システムは、当業者に明らかなように、通常、システムのオペレーションに必要な他のさまざまな入出力（Ｉ／Ｏ）サブシステム７も含む。
プロセッサは、中央処理装置ＣＰＵ８、内部キャッシュメモリ９、変換索引バッファＴＬＢ１０、および、中央バス６とインターフェースするためのバスインターフェースモジュール１１を備える。
図１は例示にすぎず、本発明は、単一のプロセッサのみを有するシステムに限定されるものではないことが理解されるべきである。
本発明は、複数のプロセッサを有するシステムでも実施することができる。
その上、不揮発性ディスク５は、中央バス６の代わりにＩ／Ｏサブシステム７に接続することもできる。
不揮発性ディスク５は、たとえば、ネットワークを介してアクセスすることができ、リモートロケーションに配置することができる。
本発明は、複数のプロセッサを有するシステムでも実施することができる。
その上、不揮発性ディスク５は、中央バス６の代わりにＩ／Ｏサブシステム７に接続することもできる。
不揮発性ディスク５は、たとえば、ネットワークを介してアクセスすることができ、リモートロケーションに配置することができる。
図２は、ソフトウェアとハードウェアとの間の相互関係を示すコンピュータシステムの高レベルの概観である。
このシステムは、ハードウェアレベル１２、カーネル１３、および、ユーザレベル１４を含む。
ハードウェアレベル１２は、図１に示すハードウェアシステム構成要素を含み、カーネル１３は、ハードウェアを制御するオペレーティングシステムの部分であり、ユーザレベル１４は、コンピュータ上で実行されているアプリケーションプログラムを含む。
プロセッサは、１つまたは複数のプロセスを実行する。
これらプロセスは、実行中のプログラムとして定義することができる。
通常、プロセス自体は多数のスレッドとして実行される。
ここで、スレッドは、オペレーティングシステムスケジューラによって実行のためにスケジューリングすることができるプロセス内のエンティティである。
また、カーネル１３は、以下でより詳細に説明するクラッシュダンプサブシステム１５も含む。
このシステムは、ハードウェアレベル１２、カーネル１３、および、ユーザレベル１４を含む。
ハードウェアレベル１２は、図１に示すハードウェアシステム構成要素を含み、カーネル１３は、ハードウェアを制御するオペレーティングシステムの部分であり、ユーザレベル１４は、コンピュータ上で実行されているアプリケーションプログラムを含む。
プロセッサは、１つまたは複数のプロセスを実行する。
これらプロセスは、実行中のプログラムとして定義することができる。
通常、プロセス自体は多数のスレッドとして実行される。
ここで、スレッドは、オペレーティングシステムスケジューラによって実行のためにスケジューリングすることができるプロセス内のエンティティである。
また、カーネル１３は、以下でより詳細に説明するクラッシュダンプサブシステム１５も含む。
図１に示すキャッシュ９、メインメモリ３、および、ハードディスク４は、すべて、プログラム命令およびデータを記憶することができる。
これらプログラム命令およびデータは通常、合わせてデータと総称される。
データは、Ｉ／Ｏサブシステム７を通じてアクセスされる外部デバイスにも記憶することができる。
カーネル１３のタスクの１つは、メモリ資源へのアクセスを管理することである。
プロセスまたはスレッドを実行するには、そのプロセスまたはスレッドに必要なデータが、ＣＰＵ８に利用可能であるように、実行時にメインメモリ３に存在しなければならない。
メインメモリ３は、物理メモリとも呼ばれる。
カーネル１３自体が、起動時にメモリにロードされると、カーネル１３は、所望のプロセスまたはスレッドを実行するのに必要な他のあらゆるデータが物理メモリ３に確実に移されるようにする。
しかしながら、ＲＡＭの量は限られており、特定のプログラムに関連付けられるすべてのデータが、ＲＡＭで最初から利用可能にされている場合、システムは、限られた個数のプログラムしか実行することができない。
したがって、ＨＰ−ＵＸＴＭ等の現代のオペレーティングシステムは仮想メモリ管理システムを作動させ、それによって、カーネルは、データおよび命令を、必要なときにハードディスク４または外部メモリデバイスからＲＡＭ３へ移動させ、もはや必要でないときに戻すことができる。
利用可能な全メモリは、仮想メモリと呼ばれ、物理メモリのサイズを超えることができる。
仮想メモリ空間の一部は、物理メモリ内に対応するアドレスを有する。
仮想メモリ空間の残りは、ハードディスク４および／または外部メモリデバイス上のアドレスにマッピングされる。
以下では、特に指定のない限り、ハードディスクからＲＡＭへデータをロードすると言うときはいずれも、他の任意の外部メモリデバイスからＲＡＭへデータをロードすることも指すものと解釈されるべきである。
これらプログラム命令およびデータは通常、合わせてデータと総称される。
データは、Ｉ／Ｏサブシステム７を通じてアクセスされる外部デバイスにも記憶することができる。
カーネル１３のタスクの１つは、メモリ資源へのアクセスを管理することである。
プロセスまたはスレッドを実行するには、そのプロセスまたはスレッドに必要なデータが、ＣＰＵ８に利用可能であるように、実行時にメインメモリ３に存在しなければならない。
メインメモリ３は、物理メモリとも呼ばれる。
カーネル１３自体が、起動時にメモリにロードされると、カーネル１３は、所望のプロセスまたはスレッドを実行するのに必要な他のあらゆるデータが物理メモリ３に確実に移されるようにする。
しかしながら、ＲＡＭの量は限られており、特定のプログラムに関連付けられるすべてのデータが、ＲＡＭで最初から利用可能にされている場合、システムは、限られた個数のプログラムしか実行することができない。
したがって、ＨＰ−ＵＸＴＭ等の現代のオペレーティングシステムは仮想メモリ管理システムを作動させ、それによって、カーネルは、データおよび命令を、必要なときにハードディスク４または外部メモリデバイスからＲＡＭ３へ移動させ、もはや必要でないときに戻すことができる。
利用可能な全メモリは、仮想メモリと呼ばれ、物理メモリのサイズを超えることができる。
仮想メモリ空間の一部は、物理メモリ内に対応するアドレスを有する。
仮想メモリ空間の残りは、ハードディスク４および／または外部メモリデバイス上のアドレスにマッピングされる。
以下では、特に指定のない限り、ハードディスクからＲＡＭへデータをロードすると言うときはいずれも、他の任意の外部メモリデバイスからＲＡＭへデータをロードすることも指すものと解釈されるべきである。
プログラムがコンパイルされるとき、コンパイラは、メモリ内のロケーションを表す、プログラムコードの仮想アドレスを生成する。
オペレーティングシステムが、その後、そのプログラムを実行している間に仮想アドレスにアクセスしようと試みるとき、システムは、特定のアドレスが物理アドレスに対応しているか否かをチェックする。
特定のアドレスが物理アドレスに対応している場合には、システムは、対応している物理アドレスのデータにアクセスする。
仮想アドレスが物理アドレスに対応していない場合には、システムは、ハードディスク４からデータを取り出し、そのデータを物理メモリ３に移動させる。
システムは、その後、通常の方法で物理メモリのデータにアクセスする。
物理メモリに十分に利用可能なメモリがない場合には、使用済みメモリを解放しなければならず、解放されるアドレスに保存されているデータおよび命令は、ハードディスク４へ移動される。
通例、物理メモリから移動されるデータは、しばらくの間使用されていないデータである。
オペレーティングシステムが、その後、そのプログラムを実行している間に仮想アドレスにアクセスしようと試みるとき、システムは、特定のアドレスが物理アドレスに対応しているか否かをチェックする。
特定のアドレスが物理アドレスに対応している場合には、システムは、対応している物理アドレスのデータにアクセスする。
仮想アドレスが物理アドレスに対応していない場合には、システムは、ハードディスク４からデータを取り出し、そのデータを物理メモリ３に移動させる。
システムは、その後、通常の方法で物理メモリのデータにアクセスする。
物理メモリに十分に利用可能なメモリがない場合には、使用済みメモリを解放しなければならず、解放されるアドレスに保存されているデータおよび命令は、ハードディスク４へ移動される。
通例、物理メモリから移動されるデータは、しばらくの間使用されていないデータである。
ページは、仮想アドレスにマッピングすることができる物理メモリの最小単位である。
たとえば、ＨＰ−ＵＸ（商標）システムでは、ページサイズは４ＫＢである。
したがって、仮想ページは、仮想ページ番号ＶＰＮによって参照される一方、物理ページは、物理ページ番号ＰＰＮによって参照される。
必要な場合にのみ仮想メモリをメインメモリに移すプロセスは、デマンドページングと呼ばれる。
たとえば、ＨＰ−ＵＸ（商標）システムでは、ページサイズは４ＫＢである。
したがって、仮想ページは、仮想ページ番号ＶＰＮによって参照される一方、物理ページは、物理ページ番号ＰＰＮによって参照される。
必要な場合にのみ仮想メモリをメインメモリに移すプロセスは、デマンドページングと呼ばれる。
図３を参照すると、さまざまな種類のメモリとデータが記憶される場所とを管理するために、ＨＰ−ＵＸ（商標）等のオペレーティングシステムは、ページディレクトリ（ＰＤＩＲ）１６と呼ばれるテーブルをメモリに保持する。
ＰＤＩＲ１６は、現在メモリにあるすべてのページを経過監視する。
ページが或る仮想アドレス空間でマッピングされるとき、そのページには、ＰＤＩＲのエントリがアロケートされる。
ＰＤＩＲは、メモリの物理ページをその仮想アドレスにリンクする。
ＰＤＩＲ１６の全てのエントリは、物理ページ番号を有するフィールド１７、仮想ページ番号を有するフィールド１８、および、メモリのページに関する少なくとも１ビットの補助情報を有する少なくとも１つのフィールド１９を含む。
ＰＤＩＲ１６は、現在メモリにあるすべてのページを経過監視する。
ページが或る仮想アドレス空間でマッピングされるとき、そのページには、ＰＤＩＲのエントリがアロケートされる。
ＰＤＩＲは、メモリの物理ページをその仮想アドレスにリンクする。
ＰＤＩＲ１６の全てのエントリは、物理ページ番号を有するフィールド１７、仮想ページ番号を有するフィールド１８、および、メモリのページに関する少なくとも１ビットの補助情報を有する少なくとも１つのフィールド１９を含む。
ＰＤＩＲ１６は、ＲＡＭ３に保存される。
システムを高速化するために、ＰＤＩＲのサブセットが、プロセッサ２のＴＬＢ１０に記憶される。
ＴＬＢは、仮想アドレスを物理アドレスに変換する。
したがって、各エントリは、仮想ページ番号および物理ページ番号の双方を含む。
システムを高速化するために、ＰＤＩＲのサブセットが、プロセッサ２のＴＬＢ１０に記憶される。
ＴＬＢは、仮想アドレスを物理アドレスに変換する。
したがって、各エントリは、仮想ページ番号および物理ページ番号の双方を含む。
本発明は、図３に示すハッシュページテーブルの配列の使用に限定されるものではなく、線形階層ページテーブル等の他のタイプのページテーブルを使用するシステムにも適用可能である。
図４を参照すると、ＣＰＵ８は、メモリページにアクセスしたいとき、最初に、ＶＰＮをインデックスとして使用してＴＬＢ１０を調べる。
ＰＰＮがＴＬＢ１０で見つかる場合、これはＴＬＢヒットと呼ばれ、プロセッサは、必要なページがメインメモリ３にあることを知る。
次に、ページからの必要なデータを、ＣＰＵ８によって使用されるキャッシュ９にロードすることができる。
キャッシュコントローラ（図示せず）は、必要なデータをキャッシュ９にロードするプロセスを制御することができる。
キャッシュコントローラは、必要なデータがキャッシュ９にすでに存在するか否かをチェックする。
必要なデータがキャッシュに存在しない場合には、キャッシュコントローラは、ＲＡＭからデータを取り出して、そのデータをキャッシュに移動させることができる。
キャッシュ９は、物理的にインデックスすることもできるし、仮想的にインデックスすることもできる。
ＰＰＮがＴＬＢ１０で見つかる場合、これはＴＬＢヒットと呼ばれ、プロセッサは、必要なページがメインメモリ３にあることを知る。
次に、ページからの必要なデータを、ＣＰＵ８によって使用されるキャッシュ９にロードすることができる。
キャッシュコントローラ（図示せず）は、必要なデータをキャッシュ９にロードするプロセスを制御することができる。
キャッシュコントローラは、必要なデータがキャッシュ９にすでに存在するか否かをチェックする。
必要なデータがキャッシュに存在しない場合には、キャッシュコントローラは、ＲＡＭからデータを取り出して、そのデータをキャッシュに移動させることができる。
キャッシュ９は、物理的にインデックスすることもできるし、仮想的にインデックスすることもできる。
ページ番号がＴＬＢで見つからない場合、これはＴＬＢミスと呼ばれ、必要なページがＰＤＩＲ１６に存在するか否かを調べるために、ＰＤＩＲ１６がチェックされる。
必要なページがＰＤＩＲ１６に存在する場合、これはＰＤＩＲヒットと呼ばれ、物理ページ番号が、ＴＬＢ１０にロードされ、ＣＰＵによってページにアクセスするための命令が再開される。
必要なページが存在しない場合、これは通常ＰＤＩＲミスと呼ばれ、これは、必要なページが物理メモリ３に存在せず、ハードディスク４または外部デバイスからメモリに必要なページを移す必要があることを示す。
ハードディスク４からメインメモリ３にページを移すプロセスは、当該技術分野で既知のように、ソフトウェアページフォールトハンドラ２０によって対処され、これによって、対応するＶＰＮ／ＰＰＮエントリがＰＤＩＲ１６およびＴＬＢ１０に作成される。
関連ページが物理メモリにロードされると、ＣＰＵによるアクセスルーチンが再開され、関連データをキャッシュにロードすることができ、ＣＰＵ８が使用することができる。
必要なページがＰＤＩＲ１６に存在する場合、これはＰＤＩＲヒットと呼ばれ、物理ページ番号が、ＴＬＢ１０にロードされ、ＣＰＵによってページにアクセスするための命令が再開される。
必要なページが存在しない場合、これは通常ＰＤＩＲミスと呼ばれ、これは、必要なページが物理メモリ３に存在せず、ハードディスク４または外部デバイスからメモリに必要なページを移す必要があることを示す。
ハードディスク４からメインメモリ３にページを移すプロセスは、当該技術分野で既知のように、ソフトウェアページフォールトハンドラ２０によって対処され、これによって、対応するＶＰＮ／ＰＰＮエントリがＰＤＩＲ１６およびＴＬＢ１０に作成される。
関連ページが物理メモリにロードされると、ＣＰＵによるアクセスルーチンが再開され、関連データをキャッシュにロードすることができ、ＣＰＵ８が使用することができる。
オペレーティングシステムのクラッシュ時に、物理メモリのデータをディスクに保存することによって、物理メモリのデータを後に解析でき、クラッシュの原因を特定することができるようにすることが多くの場合望ましい。
システムは、その後、再起動することができる。
クラッシュ時にデータをディスクに保存するプロセスを、以下では、クラッシュダンプと呼ぶ。
保存されたデータは、特定のプロセスのメモリイメージ、すなわちそのプロセスのアドレス空間の部分のメモリイメージをプロセッサレジスタの値等の他の情報と共に含むことができる。
クラッシュダンプは、カーネルのクラッシュダンプサブシステム１５で実行され、他のあらゆるアプリケーションと同様に、そのオペレーション用のメモリを必要とする。
このメモリは、物理メモリ３からアロケートしなければならない。
高性能クラッシュダンプアルゴリズムは、圧縮、並列Ｉ／Ｏ、暗号化、および、データをダンプするためのリモートストレージロケーションへのアクセスを含む。
高性能クラッシュダンプは、圧縮辞書、暗号化辞書、圧縮バッファ、および、Ｉ／Ｏバッファ用に大量のメモリを必要とする。
システムは、その後、再起動することができる。
クラッシュ時にデータをディスクに保存するプロセスを、以下では、クラッシュダンプと呼ぶ。
保存されたデータは、特定のプロセスのメモリイメージ、すなわちそのプロセスのアドレス空間の部分のメモリイメージをプロセッサレジスタの値等の他の情報と共に含むことができる。
クラッシュダンプは、カーネルのクラッシュダンプサブシステム１５で実行され、他のあらゆるアプリケーションと同様に、そのオペレーション用のメモリを必要とする。
このメモリは、物理メモリ３からアロケートしなければならない。
高性能クラッシュダンプアルゴリズムは、圧縮、並列Ｉ／Ｏ、暗号化、および、データをダンプするためのリモートストレージロケーションへのアクセスを含む。
高性能クラッシュダンプは、圧縮辞書、暗号化辞書、圧縮バッファ、および、Ｉ／Ｏバッファ用に大量のメモリを必要とする。
図５は、カーネル用の物理メモリ、クラッシュダンプ用の物理メモリ、および、ユーザプロセス用の物理メモリのアロケーションを示している。
少量のメモリが、起動時にカーネルによって確保される。
この量２１の一部は、カーネルテキスト、すなわちカーネルの必須プロセスを実行するための命令、および、初期データを含む。
カーネルテキストおよび初期データは、オペレーティングシステムがシャットダウンするまでメモリに存在しなければならず、ユーザプロセスに必要なページ用のスペースを空けるためにスワップアウトすることができない。
起動時に確保されたメモリの別の部分２２は、クラッシュダンプ用にアロケートされる。
起動時にカーネルによって確保されていないメモリ２３は、ランタイム中に仮想メモリページをマッピングするのに使用することができる。
カーネルは、物理メモリマップの形態でメモリのすべての利用可能な範囲の記録を保持する。
この物理メモリマップは、構造体のアレイであり、このアレイでは、各構造体は、メモリの利用可能な範囲の物理開始アドレスと、そのアドレスからの連続する、利用可能な物理ページの個数とを指定する。
このメモリの一部は、メモリが必要とされるときにカーネルプロセス用にアロケートされる。
その結果、カーネルデータ構造体のすべてが、連続するメモリアドレスに配置されることにはならない。
したがって、システムは、クラッシュ時に重要なカーネルデータ構造体を記憶するページのロケーションを容易に特定することができず、クラッシュダンプを実行するためにどのページを再利用してはいけないのかを容易に判断することができない。
少量のメモリが、起動時にカーネルによって確保される。
この量２１の一部は、カーネルテキスト、すなわちカーネルの必須プロセスを実行するための命令、および、初期データを含む。
カーネルテキストおよび初期データは、オペレーティングシステムがシャットダウンするまでメモリに存在しなければならず、ユーザプロセスに必要なページ用のスペースを空けるためにスワップアウトすることができない。
起動時に確保されたメモリの別の部分２２は、クラッシュダンプ用にアロケートされる。
起動時にカーネルによって確保されていないメモリ２３は、ランタイム中に仮想メモリページをマッピングするのに使用することができる。
カーネルは、物理メモリマップの形態でメモリのすべての利用可能な範囲の記録を保持する。
この物理メモリマップは、構造体のアレイであり、このアレイでは、各構造体は、メモリの利用可能な範囲の物理開始アドレスと、そのアドレスからの連続する、利用可能な物理ページの個数とを指定する。
このメモリの一部は、メモリが必要とされるときにカーネルプロセス用にアロケートされる。
その結果、カーネルデータ構造体のすべてが、連続するメモリアドレスに配置されることにはならない。
したがって、システムは、クラッシュ時に重要なカーネルデータ構造体を記憶するページのロケーションを容易に特定することができず、クラッシュダンプを実行するためにどのページを再利用してはいけないのかを容易に判断することができない。
起動時にクラッシュダンプ用にアロケートされるメモリ２２の量は、本発明によれば、実際のダンプを実行するのに必要なメモリよりもはるかに少なく、且つ、従来のダンプでアロケートされる量よりもはるかに少ない。
本発明によれば、ダンプに必要なメモリの大部分は、ランタイム中に他のプロセスが使用するのに利用可能なメモリから、クラッシュ後にアロケートされる。
以下では、クラッシュ時にメモリをアロケートするプロセスをより詳細に説明する。
本発明によれば、ダンプに必要なメモリの大部分は、ランタイム中に他のプロセスが使用するのに利用可能なメモリから、クラッシュ後にアロケートされる。
以下では、クラッシュ時にメモリをアロケートするプロセスをより詳細に説明する。
図６を参照すると、起動時にクラッシュダンプ用にアロケートされるメモリ２２は、初期圧縮バッファ２４と、初期Ｉ／Ｏバッファ２５と、圧縮辞書、暗号化辞書、および、他の必要なデータを記憶するためのメモリエリア２６と、ダンプを実行するのに必要なデータ構造体を含むメモリロケーションのリストを記憶するためのアレイ２７とを含む。
このアレイは、以下では、クラッシュダンプメモリ使用リストと呼ぶ。
このリストは、図９に関して説明するように、クラッシュ時にポピュレートされる。
また、メモリ２２は、内部資源マップ２８と、特別なクラッシュダンプページフォールトハンドラ２９用の命令と、クラッシュダンプによって使用されるＩ／Ｏドライバ３０用の命令と、内部メモリアロケータ３１用の命令とを含む。
本発明が、ページング可能カーネルを有する装置で実施される場合、すなわち、カーネルデータおよびコードを要求に応じてページングすることができる装置で実施される場合、メモリ２２のデータ構造体の少なくとも一部を、起動時ではなくクラッシュ時に物理メモリにロードすることができることが理解されるべきである。
このアレイは、以下では、クラッシュダンプメモリ使用リストと呼ぶ。
このリストは、図９に関して説明するように、クラッシュ時にポピュレートされる。
また、メモリ２２は、内部資源マップ２８と、特別なクラッシュダンプページフォールトハンドラ２９用の命令と、クラッシュダンプによって使用されるＩ／Ｏドライバ３０用の命令と、内部メモリアロケータ３１用の命令とを含む。
本発明が、ページング可能カーネルを有する装置で実施される場合、すなわち、カーネルデータおよびコードを要求に応じてページングすることができる装置で実施される場合、メモリ２２のデータ構造体の少なくとも一部を、起動時ではなくクラッシュ時に物理メモリにロードすることができることが理解されるべきである。
図７を参照すると、システムのクラッシュ時に、カーネルは、ダンプサブシステム１５に、２段階のクラッシュダンプを実行するように命令する。
最初に、ステップ７．１において、クラッシュダンプを正しく実行するためにダミークラッシュダンプが実行され、クラッシュダンプによって内部で使用されるページが特定される。
次に、ステップ７．２において、リアルダンプが、このダンプを実行するのに必要なページを含まないメモリ範囲からアロケートされたメモリを使用して実行される。
双方のダンプルーチンは、物理メモリマップをループするが、実際には、第２のダンプのみがメモリを不揮発性ストレージ５に保存する。
ダミークラッシュダンプは、図８および図９に関してより詳細に説明する。
リアルダンプは、図１０および図１１に関してより詳細に説明する。
最初に、ステップ７．１において、クラッシュダンプを正しく実行するためにダミークラッシュダンプが実行され、クラッシュダンプによって内部で使用されるページが特定される。
次に、ステップ７．２において、リアルダンプが、このダンプを実行するのに必要なページを含まないメモリ範囲からアロケートされたメモリを使用して実行される。
双方のダンプルーチンは、物理メモリマップをループするが、実際には、第２のダンプのみがメモリを不揮発性ストレージ５に保存する。
ダミークラッシュダンプは、図８および図９に関してより詳細に説明する。
リアルダンプは、図１０および図１１に関してより詳細に説明する。
図８を参照すると、ステップ８．１において、ダミークラッシュダンプルーチンは初期化される。
ダミークラッシュダンプルーチンは、不揮発性ディスク５に対するいかなる入力も出力も行われないように変更されたクラッシュダンプである。
ダミークラッシュダンプルーチンは、すべてのドライバＩ／Ｏルーチンを起動し、Ｉ／Ｏが行われないことを除いて、ダンプアルゴリズムを通じて完全に反復適用される。
また、ダミーダンプは、低メモリ動作モードで実行することもできる。
これは、ダンプ時間の削減、圧縮、暗号化等のダンプアルゴリズムによって提供される特別な改良を犠牲にして、はるかに小さなデータサイズが使用されることを意味する。
ダミークラッシュダンプルーチンは、不揮発性ディスク５に対するいかなる入力も出力も行われないように変更されたクラッシュダンプである。
ダミークラッシュダンプルーチンは、すべてのドライバＩ／Ｏルーチンを起動し、Ｉ／Ｏが行われないことを除いて、ダンプアルゴリズムを通じて完全に反復適用される。
また、ダミーダンプは、低メモリ動作モードで実行することもできる。
これは、ダンプ時間の削減、圧縮、暗号化等のダンプアルゴリズムによって提供される特別な改良を犠牲にして、はるかに小さなデータサイズが使用されることを意味する。
ステップ８．２において、カーネルページフォールトハンドラが、特定のクラッシュダンプページフォールトハンドラ２９と取り替えられる。
ステップ８．３において、補助情報を含むＰＤＩＲ１６のビット１９が、ＰＤＩＲ１６のすべての変換を無効としてマーキングするのに使用される。
ＴＬＢ１０も、ＰＤＩＲ１６の変更を反映するように更新される。
ステップ８．２およびステップ８．３の目的は、図９に関してより詳細に説明する。
ステップ８．３において、補助情報を含むＰＤＩＲ１６のビット１９が、ＰＤＩＲ１６のすべての変換を無効としてマーキングするのに使用される。
ＴＬＢ１０も、ＰＤＩＲ１６の変更を反映するように更新される。
ステップ８．２およびステップ８．３の目的は、図９に関してより詳細に説明する。
ステップ８．４において、クラッシュダンプサブシステム１５は、物理メモリマップにリストされたページの第１のセットのページ番号を取り出す。
次に、ステップ８．５において、取り出されたページからのデータが圧縮バッファ２４に読み込まれ、ステップ８．６において、データが圧縮される。
ダンプ用にアロケートされたメモリが比較的小さいことを考慮すると、一時に圧縮されるページ数も小さくなければならない。
次に、ステップ８．７において、圧縮されたデータが、圧縮バッファから入出力バッファ２５にコピーされる。
ステップ８．８において、Ｉ／Ｏドライバ３０が起動されるが、入出力バッファのデータは、ディスク５に実際に書き込まれることは決してない。
たとえば、一実施形態では、Ｉ／Ｏドライバ３０は、当該技術分野で既知のように、ダイレクトメモリアクセス（ＤＭＡ）コントローラに、データを書き込むように命令することができる。
しかしながら、ダンプがダミーダンプであるときは、Ｉ／Ｏドライバ３０は、データを書き込むための命令をＤＭＡコントローラに渡すことは決してない。
次に、ステップ８．５において、取り出されたページからのデータが圧縮バッファ２４に読み込まれ、ステップ８．６において、データが圧縮される。
ダンプ用にアロケートされたメモリが比較的小さいことを考慮すると、一時に圧縮されるページ数も小さくなければならない。
次に、ステップ８．７において、圧縮されたデータが、圧縮バッファから入出力バッファ２５にコピーされる。
ステップ８．８において、Ｉ／Ｏドライバ３０が起動されるが、入出力バッファのデータは、ディスク５に実際に書き込まれることは決してない。
たとえば、一実施形態では、Ｉ／Ｏドライバ３０は、当該技術分野で既知のように、ダイレクトメモリアクセス（ＤＭＡ）コントローラに、データを書き込むように命令することができる。
しかしながら、ダンプがダミーダンプであるときは、Ｉ／Ｏドライバ３０は、データを書き込むための命令をＤＭＡコントローラに渡すことは決してない。
次に、ステップ８．９において、カーネルサブシステム１５は、このルーチンが、物理メモリマップのすべてのページをループしたか否かをチェックする。
このルーチンが、すべてのページをループしていない場合には、物理メモリマップのすべてのページが処理されるまで、ステップ８．３〜８．９が繰り返される。
物理メモリマップのすべてのページが処理されると、このルーチンはステップ８．１０で終了する。
このルーチンが、すべてのページをループしていない場合には、物理メモリマップのすべてのページが処理されるまで、ステップ８．３〜８．９が繰り返される。
物理メモリマップのすべてのページが処理されると、このルーチンはステップ８．１０で終了する。
すべての物理メモリを必ずしもダンプしなければならないとは限らない。
たとえば、未使用のページ、ユーザプロセスページ、および、カーネルコードページは、デフォルトではダンプされない場合がある。
いくつかのオペレーティングシステムでは、クラッシュダンプサブシステム１５は、ユーザ設定をチェックして、ダンプに含まれるデータを特定することができる。
代替的には、物理メモリマップが、どのページをダンプすべきかの表示を含むことができる。
たとえば、システムは、各ページではなく、各メモリ範囲が何に使用されるのかを経過監視することができ、或るタイプのデータを含むか、または、あるプロセスに関連付けられるメモリ範囲のみをダンプに含めることができる。
図８のステップは、ダンプされるデータを含むページについてのみビジットされる。
たとえば、未使用のページ、ユーザプロセスページ、および、カーネルコードページは、デフォルトではダンプされない場合がある。
いくつかのオペレーティングシステムでは、クラッシュダンプサブシステム１５は、ユーザ設定をチェックして、ダンプに含まれるデータを特定することができる。
代替的には、物理メモリマップが、どのページをダンプすべきかの表示を含むことができる。
たとえば、システムは、各ページではなく、各メモリ範囲が何に使用されるのかを経過監視することができ、或るタイプのデータを含むか、または、あるプロセスに関連付けられるメモリ範囲のみをダンプに含めることができる。
図８のステップは、ダンプされるデータを含むページについてのみビジットされる。
ステップ８．１〜８．１０の全体を通じて、ダンプされるデータ以外のデータ構造体を含めて、クラッシュダンプデータ構造体および他のカーネルデータ構造体がアクセスされる。
ダミーダンプは、リアルダンプと同様のルーチンを起動するので、アクセスされるカーネルメモリおよびカーネルデータ構造体は、リアルダンプにも必要とされる。
したがって、カーネルメモリおよびカーネルデータ構造体を記憶するページは、リアルダンプを実行するためのメモリをアロケートするのに使用するには安全ではない。
ダンプされるデータは、物理メモリマップに記憶されている、そのデータに関連付けられる物理ページ番号を使用してアクセスされるのに対して、カーネルメモリおよびカーネルデータ構造体は、図３を参照して説明したように、それらに関連付けられる仮想ページ番号を使用してアクセスされる。
しかしながら、ＰＤＩＲ１６における物理ページ番号と仮想ページ番号との間の変換は、無効としてマーキングされているので、クラッシュダンプサブシステムを使用して、ページがそのページの仮想ページ番号を使用して最初にアクセスされるとき、特別なクラッシュダンプフォールトハンドラ２９が起動される。
このクラッシュダンプフォールトハンドラ２９は、変換がＴＬＢ１０において無効としてマーキングされていることが分かった場合も起動される。
ダミーダンプは、リアルダンプと同様のルーチンを起動するので、アクセスされるカーネルメモリおよびカーネルデータ構造体は、リアルダンプにも必要とされる。
したがって、カーネルメモリおよびカーネルデータ構造体を記憶するページは、リアルダンプを実行するためのメモリをアロケートするのに使用するには安全ではない。
ダンプされるデータは、物理メモリマップに記憶されている、そのデータに関連付けられる物理ページ番号を使用してアクセスされるのに対して、カーネルメモリおよびカーネルデータ構造体は、図３を参照して説明したように、それらに関連付けられる仮想ページ番号を使用してアクセスされる。
しかしながら、ＰＤＩＲ１６における物理ページ番号と仮想ページ番号との間の変換は、無効としてマーキングされているので、クラッシュダンプサブシステムを使用して、ページがそのページの仮想ページ番号を使用して最初にアクセスされるとき、特別なクラッシュダンプフォールトハンドラ２９が起動される。
このクラッシュダンプフォールトハンドラ２９は、変換がＴＬＢ１０において無効としてマーキングされていることが分かった場合も起動される。
より詳細には、図９を参照して、仮想ページ番号がダミークラッシュダンプルーチンによってアクセスされるごとに、ステップ９．１において、ＣＰＵはＴＬＢまたはＰＤＩＲにおいてＶＰＮを検索する。
ステップ９．２において、対応するＰＰＮが見つけられ、ステップ９．３において、ＰＤＩＲ１６の補助ビット１９またはＴＬＢの補助ビットが、変換が有効であるか否かを示すか否かがチェックされる。
変換が無効である場合、プロセスは、ステップ９．４に続き、クラッシュダンプフォールトハンドラ２９が起動される。
ステップ９．５において、特別なクラッシュダンプフォールトハンドラは、ＰＰＮがクラッシュダンプメモリ使用リスト２７に存在するか否かをチェックする。
物理ページ番号が含まれていない場合には、ステップ９．６において、物理ページ番号が保存され、次に、ステップ９．７において、ＰＤＩＲ１６の変換が有効としてマーキングされる。
次に、アドレスを変換するための命令が再開され、ステップ９．２において、ＣＰＵは物理ページ番号を見つけ、ステップ９．３において、変換が有効であることをチェックし、ステップ９．８において終了する。
ステップ９．２において、対応するＰＰＮが見つけられ、ステップ９．３において、ＰＤＩＲ１６の補助ビット１９またはＴＬＢの補助ビットが、変換が有効であるか否かを示すか否かがチェックされる。
変換が無効である場合、プロセスは、ステップ９．４に続き、クラッシュダンプフォールトハンドラ２９が起動される。
ステップ９．５において、特別なクラッシュダンプフォールトハンドラは、ＰＰＮがクラッシュダンプメモリ使用リスト２７に存在するか否かをチェックする。
物理ページ番号が含まれていない場合には、ステップ９．６において、物理ページ番号が保存され、次に、ステップ９．７において、ＰＤＩＲ１６の変換が有効としてマーキングされる。
次に、アドレスを変換するための命令が再開され、ステップ９．２において、ＣＰＵは物理ページ番号を見つけ、ステップ９．３において、変換が有効であることをチェックし、ステップ９．８において終了する。
ステップ９．５において、たとえば、仮想エイリアシングと呼ばれる、物理ページ番号が、同じ物理ページ番号にマッピングされた別の仮想ページ番号を通じてダミーダンプルーチンですでにアクセスされていたことから、その物理ページ番号がクラッシュダンプメモリ使用リスト２７にすでにあると判断された場合、プロセスは、ステップ９．７に直接続き、変換が有効としてマーキングされ、そのページにアクセスするための命令が再開される。
上述したように、ダンプされる実際の物理ページは、そのページの物理アドレスを使用してアクセスされ、変換は実行されない。
したがって、これらのアクセスは、ページフォールトにはならない。
代替的には、ページは、そのページの仮想ページ番号を使用してアクセスすることもできるが、補助ビット１９がチェックされないように、または、変換の無効フラグが無視されるように、メモリにアクセスするためのプロセスを変更することができる。
したがって、これらのページへのアクセスは、ページフォールトにならず、物理ページ番号は、リスト２９に記憶されない。
その結果、クラッシュダンプメモリ使用リスト２９は、ダンプのルーチンを実行するためにクラッシュダンプサブシステム１５によって使用されるページの物理ページ番号しか含まない。
クラッシュダンプページフォールトハンドラを起動することなくダンプされるページにアクセスする方法は、さまざまな既知の方法で実施することができ、本明細書では詳細に説明しない。
したがって、これらのアクセスは、ページフォールトにはならない。
代替的には、ページは、そのページの仮想ページ番号を使用してアクセスすることもできるが、補助ビット１９がチェックされないように、または、変換の無効フラグが無視されるように、メモリにアクセスするためのプロセスを変更することができる。
したがって、これらのページへのアクセスは、ページフォールトにならず、物理ページ番号は、リスト２９に記憶されない。
その結果、クラッシュダンプメモリ使用リスト２９は、ダンプのルーチンを実行するためにクラッシュダンプサブシステム１５によって使用されるページの物理ページ番号しか含まない。
クラッシュダンプページフォールトハンドラを起動することなくダンプされるページにアクセスする方法は、さまざまな既知の方法で実施することができ、本明細書では詳細に説明しない。
図１０を参照すると、次に、ステップ１０．１において、リアルダンプが初期化される。
ステップ１０．２において、カーネルページフォールトハンドラがリストアされる。
ステップ１０．３において、ＰＤＩＲテーブル１６に残っているすべての無効なエンティティが有効としてマーキングされる。
次に、ステップ１０．４において、当該技術分野で既知のように、ダンプを実行するメモリ要求が特定され、ステップ１０．５において、図１１に関してより詳細に説明するように、メモリをアロケートするために再利用することができるメモリ範囲が特定される。
ステップ１０．２において、カーネルページフォールトハンドラがリストアされる。
ステップ１０．３において、ＰＤＩＲテーブル１６に残っているすべての無効なエンティティが有効としてマーキングされる。
次に、ステップ１０．４において、当該技術分野で既知のように、ダンプを実行するメモリ要求が特定され、ステップ１０．５において、図１１に関してより詳細に説明するように、メモリをアロケートするために再利用することができるメモリ範囲が特定される。
再利用するのに安全なメモリ範囲にすでに記憶されているデータは、そのメモリを、クラッシュダンプサブシステム１５にアロケートすることができるようになる前にダンプしなければならない。
ステップ１０．６において、ダンプ用に再利用するのに安全なメモリ範囲のデータが、不揮発性ストレージ５に保存される。
このデータのダンプは、初期圧縮バッファ２４および初期Ｉ／Ｏバッファ２５を使用して行われる。
次に、クラッシュダンプサブシステム１５がそのデータのダンプを再び試みないように、ページが、物理メモリマップにダンプされたものとしてマーキングされる。
この時点で、メモリ範囲は、再利用されるように解放され、ステップ１０．７において、初期圧縮バッファおよび初期入出力バッファに取って代わるより大きな圧縮バッファおよび入出力バッファが、メモリ範囲からアロケートされる。
並列ダンプがカーネルによってサポートされている場合には、複数の入出力バッファを作成することができる。
加えて、マルチスレッド化された圧縮ダンプが、カーネルによってサポートされている場合には、複数の圧縮バッファを作成することができる。
ステップ１０．６において、ダンプ用に再利用するのに安全なメモリ範囲のデータが、不揮発性ストレージ５に保存される。
このデータのダンプは、初期圧縮バッファ２４および初期Ｉ／Ｏバッファ２５を使用して行われる。
次に、クラッシュダンプサブシステム１５がそのデータのダンプを再び試みないように、ページが、物理メモリマップにダンプされたものとしてマーキングされる。
この時点で、メモリ範囲は、再利用されるように解放され、ステップ１０．７において、初期圧縮バッファおよび初期入出力バッファに取って代わるより大きな圧縮バッファおよび入出力バッファが、メモリ範囲からアロケートされる。
並列ダンプがカーネルによってサポートされている場合には、複数の入出力バッファを作成することができる。
加えて、マルチスレッド化された圧縮ダンプが、カーネルによってサポートされている場合には、複数の圧縮バッファを作成することができる。
次に、ステップ１０．８において、メインダンプが開始される。
このダンプは、ここでは、十分なメモリが利用可能であるので、通常モードで行うことができる。
ステップ１０．８において、ダンプされる物理メモリマップのページの次のセットが特定され、ステップ１０．９において、それらのページに含まれるデータが、新しくアロケートされた圧縮バッファに移動される。
次に、ステップ１０．１０において、データが圧縮され、ステップ１０．１１において入出力バッファにコピーされる。
ステップ１０．１２において、ドライバルーチン３０が起動される。
この時、ステップ１０．１３において、ドライバルーチンは、ＤＭＡコントローラに、Ｉ／Ｏバッファのデータを不揮発性クラッシュダンプディスク５に書き込むように命令する。
次に、ページは、物理メモリマップにダンプされたものとしてマーキングされる。
ステップ１０．１４において、ダンプされたものとしてマーキングされてないページが物理メモリマップに残っているか否かがチェックされる。
残っている場合には、物理メモリマップのすべてのページがダンプされるまで、残っているページについて、ステップ１０．８〜１０．１４が繰り返される。
すべてのページがダンプされると、ステップ１０．１５において、ダンプは終了する。
このダンプは、ここでは、十分なメモリが利用可能であるので、通常モードで行うことができる。
ステップ１０．８において、ダンプされる物理メモリマップのページの次のセットが特定され、ステップ１０．９において、それらのページに含まれるデータが、新しくアロケートされた圧縮バッファに移動される。
次に、ステップ１０．１０において、データが圧縮され、ステップ１０．１１において入出力バッファにコピーされる。
ステップ１０．１２において、ドライバルーチン３０が起動される。
この時、ステップ１０．１３において、ドライバルーチンは、ＤＭＡコントローラに、Ｉ／Ｏバッファのデータを不揮発性クラッシュダンプディスク５に書き込むように命令する。
次に、ページは、物理メモリマップにダンプされたものとしてマーキングされる。
ステップ１０．１４において、ダンプされたものとしてマーキングされてないページが物理メモリマップに残っているか否かがチェックされる。
残っている場合には、物理メモリマップのすべてのページがダンプされるまで、残っているページについて、ステップ１０．８〜１０．１４が繰り返される。
すべてのページがダンプされると、ステップ１０．１５において、ダンプは終了する。
ここで、図１１に関してステップ１０．５をより詳細に説明する。
ステップ１１．１において、クラッシュダンプサブシステム１５が、内部クラッシュダンプメモリアロケータルーチン３１を起動する。
ステップ１１．２において、メモリアロケータは物理メモリマップにアクセスする。
図５に示すように、メモリの部分２１は、起動時にメモリにロードされるカーネルの静的データセグメントおよびテキストセグメントを含む。
メモリのこの部分のデータは、カーネルを実行するのに必要とされ、メモリの一部はクラッシュダンプを実行するのに再利用することができるが、この部分２１の再利用を回避することが最も安全である。
したがって、ステップ１１．３において、メモリアロケータは、メモリエリア２１において起動時にメモリにロードされるカーネルの静的データセグメントおよびテキストセグメントを通じて反復適用され、カーネルの静的データセグメントおよびテキストセグメントに使用される物理ページの最大値を特定し、ステップ１１．４において、メモリアロケータは、カーネルの静的データセグメントおよびテキストセグメントに使用される物理ページの最大値よりも上で、クラッシュダンプメモリ使用リスト２７内のいかなるページも含まない最も広いページ範囲を検索する。
次に、メモリアロケータは、特定された範囲を有するそれ自身の資源マップ２８を初期化する。
次に、図１０のステップ１０．６および１０．７に関して説明したように、特定された範囲のデータは、ダンプおよび再利用することができる。
ステップ１１．１において、クラッシュダンプサブシステム１５が、内部クラッシュダンプメモリアロケータルーチン３１を起動する。
ステップ１１．２において、メモリアロケータは物理メモリマップにアクセスする。
図５に示すように、メモリの部分２１は、起動時にメモリにロードされるカーネルの静的データセグメントおよびテキストセグメントを含む。
メモリのこの部分のデータは、カーネルを実行するのに必要とされ、メモリの一部はクラッシュダンプを実行するのに再利用することができるが、この部分２１の再利用を回避することが最も安全である。
したがって、ステップ１１．３において、メモリアロケータは、メモリエリア２１において起動時にメモリにロードされるカーネルの静的データセグメントおよびテキストセグメントを通じて反復適用され、カーネルの静的データセグメントおよびテキストセグメントに使用される物理ページの最大値を特定し、ステップ１１．４において、メモリアロケータは、カーネルの静的データセグメントおよびテキストセグメントに使用される物理ページの最大値よりも上で、クラッシュダンプメモリ使用リスト２７内のいかなるページも含まない最も広いページ範囲を検索する。
次に、メモリアロケータは、特定された範囲を有するそれ自身の資源マップ２８を初期化する。
次に、図１０のステップ１０．６および１０．７に関して説明したように、特定された範囲のデータは、ダンプおよび再利用することができる。
図１１に関して説明したプロセスは、再利用するのに安全なメモリ範囲を特定するためのプロセスの単なる一例を構成するにすぎないことが理解されるべきである。
このプロセスの詳細は変更可能である。
たとえば、ステップ１１．３は、実行されない場合があり、カーネルの静的データセグメントおよびテキストセグメント用に確保されたメモリの部分２１を、クラッシュダンプルーチン用に再利用するのに安全なメモリ範囲を得るために検索することもできる。
このプロセスの詳細は変更可能である。
たとえば、ステップ１１．３は、実行されない場合があり、カーネルの静的データセグメントおよびテキストセグメント用に確保されたメモリの部分２１を、クラッシュダンプルーチン用に再利用するのに安全なメモリ範囲を得るために検索することもできる。
一実施形態では、ダミークラッシュダンプルーチンおよびリアルクラッシュダンプルーチンは、ソフトウェアを使用して実施される。
カーネルは、ダンプがダミーダンプであるのか、または、リアルダンプであるのかを示す変数と、ダンプされるデータを特定するのに使用される資源マップを指し示す変数との２つの変数を取り入れるクラッシュダンプ関数をコールすることができる。
ダンプがダミーダンプであるのか、または、リアルダンプであるのかを示す変数の値に応じて、初期バッファがアクセスされるのか、または、クラッシュ時にアロケートされたバッファがアクセスされるのかが決定される。
この関数は、変数をドライバルーチンにも渡すことができる。
ドライバルーチンは、変数の値に基づいて、ＤＭＡコントローラに、ダンプされるデータを不揮発性ストレージに書き込むように命令するか否かを決定する。
実際のダンプ用のメモリは、Ｃの関数malloc()を使用してアロケートすることができる。
この関数malloc()は、当該技術分野において既知である。
一実施形態では、特別なcrashdump_malloc()関数を提供することができる。
この関数は、内部クラッシュダンプメモリ資源マップからメモリをアロケートするように記述することができる。
カーネルは、ダンプがダミーダンプであるのか、または、リアルダンプであるのかを示す変数と、ダンプされるデータを特定するのに使用される資源マップを指し示す変数との２つの変数を取り入れるクラッシュダンプ関数をコールすることができる。
ダンプがダミーダンプであるのか、または、リアルダンプであるのかを示す変数の値に応じて、初期バッファがアクセスされるのか、または、クラッシュ時にアロケートされたバッファがアクセスされるのかが決定される。
この関数は、変数をドライバルーチンにも渡すことができる。
ドライバルーチンは、変数の値に基づいて、ＤＭＡコントローラに、ダンプされるデータを不揮発性ストレージに書き込むように命令するか否かを決定する。
実際のダンプ用のメモリは、Ｃの関数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
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[]に保存する
プロセッサの特別なレジスタからフォールト仮想アドレス「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[]からメモリをアロケートする
カーネルの静的データセグメント、テキストセグメントを通じて反復適用され、使用される物理ページの最大値kernel_static_phys_maxを特定する
カーネルの物理メモリマップを反復し、kernel_static_phys_maxよりも上で検索を開始して、crashdump_memory_usage[]に存在しない最も広いページ範囲を特定する
上記範囲を有する資源マップcrashdump_rmap[]を初期化する
crashdump_malloc()
crashdump_rmap[]からメモリをアロケートする
上記特定の実施形態に関して本発明を説明してきたが、変形が可能である。
たとえば、ＰＤＩＲ１６において補助情報を含むビット１９を無効としてマーキングする代わりに、ダンプに必要なカーネルデータ構造体を含むページを、他の或るページ保護メカニズムを使用してフォールトハンドラを起動することによってログ記録することができる。
たとえば、ページテーブルの無効／有効ビットの代わりに、メモリの特定のブロックに関連付けられる保護キーまたはタスク識別子を使用することができる。
たとえばPA-RISCTMプロセッサで使用される保護キーおよびタスク識別子は、当該技術分野で既知であるので、ここでは詳細に説明しない。
たとえば、ページテーブルの無効／有効ビットの代わりに、メモリの特定のブロックに関連付けられる保護キーまたはタスク識別子を使用することができる。
たとえばPA-RISCTMプロセッサで使用される保護キーおよびタスク識別子は、当該技術分野で既知であるので、ここでは詳細に説明しない。
その上、いくつかのオペレーティングシステムでは、クラッシュダンプルーチンは、リアルモードで実行されることに留意すべきである。
換言すれば、いかなるアクセスチェックまたは保護チェックも行われない。
その場合、ＣＰＵがアクセスチェックおよび保護チェックを行うように、ダミーダンプは、仮想モードで実行することができ、実際のダンプは、フェールセーフオペレーションのリアルモードまたは物理モードで実行することができる。
換言すれば、いかなるアクセスチェックまたは保護チェックも行われない。
その場合、ＣＰＵがアクセスチェックおよび保護チェックを行うように、ダミーダンプは、仮想モードで実行することができ、実際のダンプは、フェールセーフオペレーションのリアルモードまたは物理モードで実行することができる。
加えて、メモリは、ページに分割される必要はない。
メモリの他のタイプのセグメンテーションも可能である。
メモリの他のタイプのセグメンテーションも可能である。
本発明は、ダンプの目的で、システムクラッシュ後にメモリをアロケートするメカニズムを提供する。
その上、このメカニズムが必要とするメモリの記録保持（book keeping）は、従来技術よりも少ない。
その上、本発明によるメモリをアロケートするメカニズムを使用することによって、クラッシュダンプルーチンを開始するために起動中またはランタイム中に確保しなければならないメモリは、少量のみである。
その結果、装置は、従来技術よりも効率的にメモリを使用する。
その上、このメカニズムが必要とするメモリの記録保持（book keeping）は、従来技術よりも少ない。
その上、本発明によるメモリをアロケートするメカニズムを使用することによって、クラッシュダンプルーチンを開始するために起動中またはランタイム中に確保しなければならないメモリは、少量のみである。
その結果、装置は、従来技術よりも効率的にメモリを使用する。
ダミークラッシュダンプを実行するのに要する時間は、クラッシュダンププロセスが完了するのに要する時間を大幅に延ばさないことに留意すべきである。
その理由は、データを不揮発性ディスクに書き込む、多くの時間を要するタスクが、ダミークラッシュダンプルーチンでは行われないからである。
その理由は、データを不揮発性ディスクに書き込む、多くの時間を要するタスクが、ダミークラッシュダンプルーチンでは行われないからである。
その上、クラッシュダンププロセスが完了するのに要する時間は、時に、ダミークラッシュダンプの一部としての圧縮または暗号化を行わないことによって、さらに削減することができる。
本発明によるクラッシュダンププロセスに要する時間は、ダミークラッシュダンプで使用されるより小さなデータサイズで実際のダンプが行われた場合よりも短い。
したがって、本発明によって、クラッシュダンプが完了するのに要する時間を大幅に延ばすことなくメモリのより効率的な使用が可能になる。
本発明によるクラッシュダンププロセスに要する時間は、ダミークラッシュダンプで使用されるより小さなデータサイズで実際のダンプが行われた場合よりも短い。
したがって、本発明によって、クラッシュダンプが完了するのに要する時間を大幅に延ばすことなくメモリのより効率的な使用が可能になる。
圧縮を含むようにクラッシュダンプアルゴリズムを説明してきたが、本発明は、圧縮が使用されないときにも利点を有する。
たとえば暗号化または並列Ｉ／Ｏを使用することから、かなりの量のメモリを使用するクラッシュダンプアルゴリズムを有するいかなるシステムも、ダンプを実行するのに必要なすべてのメモリが起動時にアロケートされる場合には、メモリの使用が非効率的になる。
本発明によれば、必要なメモリの大部分は、起動時ではなくクラッシュ時にアロケートすることができる。
ランタイム中に他のプロセスに使用されるメモリをクラッシュ時に再利用することができ、メモリはより効率的に使用される。
たとえば暗号化または並列Ｉ／Ｏを使用することから、かなりの量のメモリを使用するクラッシュダンプアルゴリズムを有するいかなるシステムも、ダンプを実行するのに必要なすべてのメモリが起動時にアロケートされる場合には、メモリの使用が非効率的になる。
本発明によれば、必要なメモリの大部分は、起動時ではなくクラッシュ時にアロケートすることができる。
ランタイム中に他のプロセスに使用されるメモリをクラッシュ時に再利用することができ、メモリはより効率的に使用される。
１・・・処理システム，
２・・・プロセッサ，
３・・・メインメモリ，
４・・・ハードディスク，
５・・・不揮発性ディスク
６・・・バス，
７・・・他のＩ／Ｏ，
９・・・キャッシュ，
１１・・・バスインターフェース，
１２・・・ハードウェア，
１３・・・カーネル，
１４・・・アプリケーションプログラム，
１５・・・クラッシュダンプサブシステム，
１９・・・補助情報，
２０・・・ページフォールトハンドラ，
２１・・・初期カーネルテキストおよび初期カーネルデータ，
２２・・・ダンプ用のメモリ，
２３・・・利用可能なメモリ，
２４・・・圧縮バッファ，
２５・・・Ｉ／Ｏバッファ，
２６・・・辞書等，
２７・・・クラッシュダンプメモリ使用リスト，
２８・・・資源マップ，
２９・・・ページフォールトハンドラ，
３０・・・Ｉ／Ｏドライバ，
３１・・・メモリアロケータ，
２・・・プロセッサ，
３・・・メインメモリ，
４・・・ハードディスク，
５・・・不揮発性ディスク
６・・・バス，
７・・・他のＩ／Ｏ，
９・・・キャッシュ，
１１・・・バスインターフェース，
１２・・・ハードウェア，
１３・・・カーネル，
１４・・・アプリケーションプログラム，
１５・・・クラッシュダンプサブシステム，
１９・・・補助情報，
２０・・・ページフォールトハンドラ，
２１・・・初期カーネルテキストおよび初期カーネルデータ，
２２・・・ダンプ用のメモリ，
２３・・・利用可能なメモリ，
２４・・・圧縮バッファ，
２５・・・Ｉ／Ｏバッファ，
２６・・・辞書等，
２７・・・クラッシュダンプメモリ使用リスト，
２８・・・資源マップ，
２９・・・ページフォールトハンドラ，
３０・・・Ｉ／Ｏドライバ，
３１・・・メモリアロケータ，
Claims (18)
- データ処理装置においてメモリのクラッシュダンプを実行する方法であって、
起動時にアロケートされたメモリを使用して、第２のルーチンによってダンプされるデータのメモリロケーションを前記ダンプされるデータの物理ページ番号を用いてアクセスし、当該仮想ページ番号を用いてアクセスされるときに、前記第２のルーチンを実行するためのデータのメモリロケーションを特定するクラッシュダンプページフォールトハンドラが起動される、第１のルーチンを実行することと、
前記特定されたメモリロケーションを含まないメモリ範囲から前記第２のルーチンにおいて前記ダンプされるデータが移動されるメモリをアロケートすることと、
前記アロケートされたメモリを使用して前記第２のルーチンを実行することと
を含み、
前記第１のルーチンは、
ディスクに対するいかなる入出力も行われないように変更されたクラッシュダンプであるダミークラッシュダンプルーチン
を含み、
前記第２のルーチンは、
クラッシュダンプルーチン
を含む
方法。 - 前記ダミークラッシュダンプルーチンは、前記クラッシュダンプルーチンよりも小さなデータサイズを使用する
請求項１に記載の方法。 - 前記ダミークラッシュダンプルーチンの前記実行は、カーネルクラッシュによってトリガされる
請求項１に記載の方法。 - 前記データ処理装置は、
仮想メモリ管理システム
を備え、
前記データのメモリロケーションを特定する前記ダミークラッシュダンプルーチンを実行することは、
前記ダミークラッシュダンプルーチンによってアクセスされる仮想ページアドレスに対応する物理ページアドレスの記録を作成すること
を含む
請求項１に記載の方法。 - 前記ダミークラッシュダンプルーチンを実行することは、
仮想ページアドレスが前記ダミークラッシュダンプルーチンによってアクセスされるときにクラッシュダンプページフォールトハンドラを起動すること
をさらに含み、
前記仮想ページアドレスに対応する前記物理ページアドレスを保存することは、前記クラッシュダンプページフォールトハンドラによって実行される
請求項４に記載の方法。 - 前記装置のページテーブルのすべての変換を無効としてマーキングすることであって、前記ダミークラッシュダンプルーチンの期間中に前記クラッシュダンプページフォールトハンドラを起動する、マーキングすること
をさらに含む請求項５に記載の方法。 - 前記特定されたメモリロケーションを含まないメモリ範囲を特定することと、
前記クラッシュダンプルーチンの実行用メモリを前記メモリ範囲からアロケートする前に、前記メモリ範囲のデータを不揮発性ストレージに保存することと
をさらに含む請求項１に記載の方法。 - 前記クラッシュダンプルーチンの実行用メモリをアロケートすることは、
少なくとも１つの圧縮バッファ用のメモリをアロケートすること
を含む請求項１に記載の方法。 - 前記クラッシュダンプルーチンの実行用メモリをアロケートすることは、
並列Ｉ／Ｏの実行用の複数のバッファをアロケートすること
を含む請求項１に記載の方法。 - 前記クラッシュダンプルーチンを実行することは、
圧縮アルゴリズム、並列Ｉ／Ｏオペレーションアルゴリズム、暗号化アルゴリズムおよびネットワークを介して不揮発性ストレージに書き込むアルゴリズムの１つ以上を実行すること
を含む
請求項１に記載の方法。 - データ処理装置においてメモリのクラッシュダンプをコンピュータに実行させるプログラムであって、
起動時にアロケートされたメモリを使用して、第２のルーチンによってダンプされるデータのメモリロケーションを前記ダンプされるデータの物理ページ番号を用いてアクセスし、第２のルーチンを実行するためのデータに仮想ページ番号を用いてアクセスし、当該仮想ページ番号を用いてアクセスされるときに、前記第２のルーチンを実行するためのデータのメモリロケーションを特定するクラッシュダンプページフォールトハンドラが起動される、第１のルーチンを実行する処理ユニットと、
前記特定されたメモリロケーションを含まないメモリ範囲から前記第２のルーチンにおいて前記ダンプされるデータが移動されるメモリをアロケートするメモリアロケータと
を前記コンピュータに実行させ、
前記処理ユニットは、前記メモリアロケータによってアロケートされた前記メモリを使用して前記第２のルーチンを、前記コンピュータにさらに実行させ
前記第１のルーチンは、
ディスクに対するいかなる入出力も行われないように変更されたクラッシュダンプであるダミークラッシュダンプルーチン
を前記コンピュータに実行させ、
前記第２のルーチンは、
クラッシュダンプルーチン
を前記コンピュータに実行させる
プログラム。 - 前記処理ユニットは、低メモリ動作モードで、前記ダミークラッシュダンプルーチンを、前記コンピュータに実行させるように構成される
請求項１１に記載のプログラム。 - 前記処理ユニットは、前記コンピュータに、仮想メモリアドレスを使用して、前記データ処理装置のメモリにアドレスさせ、
前記プログラムは、
前記コンピュータに、前記ダミークラッシュダンプルーチンの期間中にアクセスされる仮想アドレスに対応する物理アドレスを保存させる内部メモリ
をさらに備える
請求項１１に記載のプログラム。 - 前記ページフォールトハンドラは、前記ダミークラッシュダンプルーチンの期間中にアクセスされた仮想アドレスに対応する物理アドレスを、前記コンピュータに保存させる
請求項１１に記載のプログラム。 - 前記処理ユニットは、前記コンピュータに、前記データ処理装置のページテーブルのすべての変換を無効としてマーキングさせ、前記ダミークラッシュダンプルーチンの期間中に前記クラッシュダンプページフォールトハンドラを起動させる
請求項１４に記載のプログラム。 - 前記メモリアロケータは、前記コンピュータに、前記特定されたメモリロケーションを含まないメモリ範囲を特定させ、
前記処理ユニットは、前記コンピュータに、実際のダンプの実行用メモリを前記メモリ範囲からアロケートする前に、前記メモリ範囲のデータを、不揮発性ストレージに保存させる
請求項１１に記載のプログラム。 - カーネルを構成する
請求項１１に記載のプログラム。 - メモリと、
カーネルと、
前記カーネルのクラッシュ時に、前記メモリの第２の部分のクラッシュダンプに使用される前記メモリの第１の部分をアロケートするメモリアロケータと、
前記カーネルのクラッシュ時に前記メモリの前記第２の部分を不揮発性ストレージに保存するクラッシュダンプモジュールと、
を備える装置であって、
前記クラッシュダンプモジュールは、前記カーネルのクラッシュ時に、ディスクに対するいかなる入出力も行われないように変更されたクラッシュダンプであるダミークラッシュダンプルーチンを、起動時にアロケートされたメモリを使用して実行して、クラッシュダンプルーチンによってダンプされるデータに、前記ダンプされるデータのメモリロケーションである物理ページ番号を用いてアクセスし、クラッシュダンプルーチンを実行するのに使用されるカーネルデータ構造体に仮想ページ番号を用いてアクセスし、当該仮想ページ番号を用いてアクセスされるときに、前記カーネルデータ構造体のメモリロケーションを特定するクラッシュダンプページフォールトハンドラが起動されるようにさらに動作し、
前記メモリアロケータは、前記特定されたカーネルデータ構造体を含まないメモリ範囲を特定して、前記特定されたメモリ範囲から前記クラッシュダンプにおいて前記第２の部分のデータが移動される前記メモリの前記第１の部分をアロケートする
装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| IN1524CH2007 | 2007-07-16 | ||
| IN1524/CHE/2007 | 2007-07-16 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2009032252A JP2009032252A (ja) | 2009-02-12 |
| JP5255348B2 true JP5255348B2 (ja) | 2013-08-07 |
Family
ID=40265800
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008176598A Expired - Fee Related JP5255348B2 (ja) | 2007-07-16 | 2008-07-07 | クラッシュダンプ用のメモリアロケーション |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US8453015B2 (ja) |
| JP (1) | JP5255348B2 (ja) |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8375386B2 (en) * | 2005-06-29 | 2013-02-12 | Microsoft Corporation | Failure management for a virtualized computing environment |
| US7506203B2 (en) * | 2005-11-10 | 2009-03-17 | International Business Machines Corporation | Extracting log and trace buffers in the event of system crashes |
| KR101658485B1 (ko) * | 2009-06-18 | 2016-09-22 | 삼성전자주식회사 | 휴대용 단말기에서 디버깅을 위한 부팅 방법 및 장치 |
| JP5359601B2 (ja) * | 2009-06-25 | 2013-12-04 | 富士通株式会社 | ダンプ出力制御装置、ダンプ出力制御プログラム、ダンプ出力制御方法 |
| GB2471480A (en) * | 2009-06-30 | 2011-01-05 | Nokia Corp | Preventing boot crashes due to new files |
| US8671405B2 (en) | 2010-03-31 | 2014-03-11 | Microsoft Corporation | Virtual machine crash file generation techniques |
| US8862930B2 (en) * | 2010-11-24 | 2014-10-14 | Red Hat, Inc. | Crash recovery memory reservation based on device drivers for an operational kernel |
| US8621282B1 (en) | 2011-05-19 | 2013-12-31 | Google Inc. | Crash data handling |
| US8607098B2 (en) * | 2011-05-26 | 2013-12-10 | International Business Machines Corporation | Generating appropriately sized core files used in diagnosing application crashes |
| US9921967B2 (en) | 2011-07-26 | 2018-03-20 | Intel Corporation | Multi-core shared page miss handler |
| WO2013080313A1 (ja) * | 2011-11-30 | 2013-06-06 | 株式会社日立製作所 | メモリダンプ採取手法 |
| US9003223B2 (en) * | 2012-09-27 | 2015-04-07 | International Business Machines Corporation | Physical memory fault mitigation in a computing environment |
| GB2508344A (en) * | 2012-11-28 | 2014-06-04 | Ibm | Creating an operating system dump |
| US9348533B2 (en) | 2013-03-14 | 2016-05-24 | Microsoft Technology Licensing, Llc | Memory image capture via memory write from a running system |
| US9286152B2 (en) * | 2013-06-14 | 2016-03-15 | Microsoft Technology Licensing, Llc | Securely obtaining memory content after device malfunction |
| US20150006962A1 (en) * | 2013-06-27 | 2015-01-01 | Robert C. Swanson | Memory dump without error containment loss |
| JP2015114750A (ja) | 2013-12-10 | 2015-06-22 | 富士通株式会社 | 調査用プログラム，情報処理装置及び情報処理方法 |
| JP2016170463A (ja) * | 2015-03-11 | 2016-09-23 | 富士通株式会社 | 情報処理装置、カーネルダンプ方法、カーネルダンププログラム |
| US9852028B2 (en) * | 2015-04-21 | 2017-12-26 | International Business Machines Corporation | Managing a computing system crash |
| US9727242B2 (en) | 2015-06-10 | 2017-08-08 | International Business Machines Corporation | Selective memory dump using usertokens |
| US10013299B2 (en) | 2015-09-16 | 2018-07-03 | Microsoft Technology Licensing, Llc | Handling crashes of a device's peripheral subsystems |
| US10169130B2 (en) * | 2016-07-19 | 2019-01-01 | International Business Machines Corporation | Tailoring diagnostic information in a multithreaded environment |
| US11113190B2 (en) | 2016-11-11 | 2021-09-07 | Microsoft Technology Licensing, Llc | Mutable type builder |
| KR102518881B1 (ko) | 2017-01-09 | 2023-04-05 | 삼성전자주식회사 | 반도체 장치의 동작 방법 |
| WO2018148923A1 (en) * | 2017-02-17 | 2018-08-23 | Intel Corporation | Application and system fast launch by virtual address area container |
| US10169198B2 (en) * | 2017-04-24 | 2019-01-01 | International Business Machines Corporation | Aggregating data for debugging software |
| US12019772B2 (en) * | 2021-09-14 | 2024-06-25 | International Business Machines Corporation | Storing diagnostic state of secure virtual machines |
| CN114115025B (zh) * | 2021-11-24 | 2024-05-28 | 国汽智控(北京)科技有限公司 | 基于自动驾驶系统的故障信息的保存方法、装置和设备 |
| CN114327980B (zh) * | 2021-12-27 | 2025-01-03 | 北京和利时系统工程有限公司 | 获取线程崩溃地址的方法及装置 |
| CN119248673B (zh) * | 2024-02-21 | 2025-08-08 | 荣耀终端股份有限公司 | 数据转储方法与电子设备 |
| US12541420B2 (en) | 2024-06-25 | 2026-02-03 | Hewlett Packard Enterprise Development Lp | Storing device health data in persistent storage |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0743676B2 (ja) * | 1988-03-11 | 1995-05-15 | 株式会社日立製作所 | バツクアツプデータダンプ制御方法及び装置 |
| US5293612A (en) * | 1989-05-11 | 1994-03-08 | Tandem Computers Incorporated | Selective dump method and apparatus |
| US6543010B1 (en) * | 1999-02-24 | 2003-04-01 | Hewlett-Packard Development Company, L.P. | Method and apparatus for accelerating a memory dump |
| JP2002073378A (ja) * | 2000-09-04 | 2002-03-12 | Hitachi Ltd | 計算機システムのダンプ取得方法および装置 |
| US6687799B2 (en) * | 2002-01-31 | 2004-02-03 | Hewlett-Packard Development Company, L.P. | Expedited memory dumping and reloading of computer processors |
| US20040025093A1 (en) * | 2002-07-31 | 2004-02-05 | Jeff Willy | System and method for collecting code coverage information on fatal error path code |
| US7509521B2 (en) * | 2004-08-23 | 2009-03-24 | Microsoft Corporation | Memory dump generation with quick reboot |
| JP4677214B2 (ja) * | 2004-09-06 | 2011-04-27 | 富士通株式会社 | パニックダンプ採取のためのプログラム、方法、及び機構 |
| US7484127B2 (en) * | 2005-01-13 | 2009-01-27 | Nokia Siemens Networks Oy | Method and system for preserving crash dump in a diskless system |
| US20080195836A1 (en) * | 2005-02-23 | 2008-08-14 | Hewlett-Packard Development Company, L.P. | Method or Apparatus for Storing Data in a Computer System |
| US7831857B2 (en) * | 2006-10-31 | 2010-11-09 | Hewlett-Packard Development Company, L.P. | Method and system for recovering from operating system crash or failure |
| US7707462B1 (en) * | 2007-04-24 | 2010-04-27 | Netapp, Inc. | Non-disruptive generation of core files without reboot |
-
2008
- 2008-07-07 JP JP2008176598A patent/JP5255348B2/ja not_active Expired - Fee Related
- 2008-07-16 US US12/174,194 patent/US8453015B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20090024820A1 (en) | 2009-01-22 |
| JP2009032252A (ja) | 2009-02-12 |
| US8453015B2 (en) | 2013-05-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5255348B2 (ja) | クラッシュダンプ用のメモリアロケーション | |
| US9836409B2 (en) | Seamless application access to hybrid main memory | |
| JP4366012B2 (ja) | 仮想記憶システムにおいてアプリケーションプログラムによってコードまたはデータをグループに分類して、物理メモリの割り振りの制御を行うアプリケーション・プログラミング・インターフェイス | |
| KR100734823B1 (ko) | 메모리 압축된 머신을 모핑하는 방법 및 장치 | |
| US9213623B2 (en) | Memory allocation with identification of requesting loadable kernel module | |
| US20080235477A1 (en) | Coherent data mover | |
| US11354233B2 (en) | Method and system for facilitating fast crash recovery in a storage device | |
| US9081692B2 (en) | Information processing apparatus and method thereof | |
| JP5071798B2 (ja) | 計算機システム，メモリ管理方法，およびそのプログラム | |
| CN110955495A (zh) | 虚拟化内存的管理方法、装置和存储介质 | |
| US20110087901A1 (en) | Fast speed computer system power-on & power-off method | |
| JP2024527054A (ja) | 動的割当可能な物理的にアドレス指定されるメタデータストレージ | |
| KR20080017292A (ko) | 내장 시스템들을 위한 저장 아키텍쳐 | |
| CN120104043A (zh) | 一种数据处理方法、装置和计算设备 | |
| EP1103898A2 (en) | Microprocessor and memory | |
| US20090031100A1 (en) | Memory reallocation in a computing environment | |
| JP4792065B2 (ja) | データ記憶方法 | |
| US20080072009A1 (en) | Apparatus and method for handling interrupt disabled section and page pinning apparatus and method | |
| Dolev et al. | Memory management for self-stabilizing operating systems | |
| EP0262301A2 (en) | Paging supervisor | |
| CN120216227A (zh) | 一种缺页异常的处理方法、装置及设备 | |
| CN119862035A (zh) | 内存数据获取方法、装置、车载设备及车辆 | |
| JP2004355187A (ja) | 仮想メモリ・システム、仮想メモリのアドレス管理方法、並びにアドレス変換テーブル生成装置 | |
| JP2014157434A (ja) | プログラム生成方法、プログラム実行方法、プログラム生成装置、プログラム生成プログラム、プログラム実行装置およびプログラム実行プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110909 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110913 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20111208 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120322 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120601 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20120802 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20121113 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20121120 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20121213 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130306 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20130325 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130419 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5255348 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20160426 Year of fee payment: 3 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R371 | Transfer withdrawn |
Free format text: JAPANESE INTERMEDIATE CODE: R371 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |