JP2009129101A - 情報処理装置の障害処理システム - Google Patents

Abstract

【課題】複数のプロセッサコアが、多数アプリケーションソフトウェア（以下ＡＰと称す）を同時並列実行するＣＰＵで、特定プロセッサコアに特定処理を割り当てる場合、障害発生プロセッサコアで、次のＡＰの迅速動作が出来ない。
【解決手段】複数のプロセッサコアの１つを障害処理プロセッサコアとし、他プロセッサコア上のＯＳは初期化時に自障害処理手段を障害処理プロセッサコアに登録し、動作中のＡＰに障害が起きた時、最低限のハードウェア情報保存後、障害発生ＡＰを停止、障害処理用プロセッサコアに障害を通知、次動作ＡＰをスケジューリング対象とし、障害処理用プロセッサコアは障害情報の収集／記録、障害の対処決定後、障害発生プロセッサコアに障害処理完了を通知、障害発生プロセッサは障害発生ＡＰ動作状態を削除し、次ＡＰの動作迅速化、複数ＯＳ構成での１つの構成による障害処理が可能。
【選択図】図１

Description

この発明は、複数のプロセッサコアを持ち、それぞれのプロセッサコアがメモリを共有しているようなハードウェア構成における情報処置装置の障害処理システムに関するものである。

近年、半導体の微細化技術の進展により、１つのＣＰＵ（Central Processor Unit）上に複数のプロセッサコアを搭載し、多数のアプリケーションソフトウェア処理を並列に同時実行させることができるマルチコア技術を備えたＣＰＵが製品化されてきている。マルチコアを備えたＣＰＵでは、異なる処理をそれぞれ別のプロセッサコアで処理させることにより、全体の処理性能を向上させることができる。しかしながら、１つのプロセッサコア上でアプリケーションソフトウェア（以下ＡＰと称す）に障害が発生した場合、従来ではそのプロセッサコア上にて、ＡＰの障害情報の収集・対処が行われるため、障害状態の保存に時間が掛かると共に、そのプロセッサコア上の処理負荷が高くなるという問題があった。

障害情報の収集・対処処理時間の短縮、およびプロセッサコアの処理負荷を軽減する方法として、例えば、特開平１１−３３８８３８号公報に記載の方法がある。この方法では、複数のＣＰＵを備えたマルチプロセッサシステムにおいて、１つのＣＰＵにて障害を検出した場合、そのＣＰＵから他のＣＰＵに対して障害情報採取の指示を出し、障害検出ＣＰＵ以外の複数のＣＰＵで、障害情報の採取量が均等になるように配分して並列に障害情報を採取し、記録することで、障害情報採取時間を短縮することができるとしている。

また、特開平１１−２９６４９２号公報の記載では、複数の計算機を備え、同一の業務処理プログラムが何れの計算機でも実行可能なマルチ計算機システムにおいて、ある計算機で障害が発生した場合に、システム内で正常に動作している他の計算機の中で、その時点において最も動作負荷の低い計算機により、障害が発生した計算機が処理していた業務をリカバリ処理して、業務処理を滞らせることなく、リカバリ処理を迅速に行うことができるとしている。

さらに、特開平３−７３０３３号公報の記載では、障害情報の収集および記録を専門に行う診断装置がある構成において、この診断装置にて障害情報の収集を行う際、診断装置内にあるディスク装置に直接障害情報を格納せず、別の記憶手段に一時的に障害情報を蓄え、その記憶手段内の情報を元に、障害解析を行うようにすることで、障害対処に要する時間を少なくすることができるとしている。

特開平１１−３３８８３８号公報 特開平１１−２９６４９２号公報 特開平３−７３０３３号公報

しかし、上記従来技術においては、組込み装置など、特定のプロセッサコアに特定の処理を割り当てているようなシステムの場合、障害が発生したプロセッサコアで、次に動作するＡＰを迅速に動作させることが出来ない。

例えば、特開平１１−３３８８３８号公報に記載の方法では、障害情報の採取を複数のＣＰＵに分割して並列処理させるものの、その処理中は、次に動作すべきＡＰを動作させることができない。

また、特開平１１−２９６４９２号公報に記載の方法では、全てのプロセッサコアで同一の処理を行うことを想定しており、それぞれのプロセッサコアが特定のＡＰを動作させるような構成の場合、他のプロセッサコアがリカバリ処理をすることができない。また他のプロセッサコアにてリカバリ処理ができたとしても、リカバリ処理を行うプロセッサコアにＡＰプログラムを移送する際、障害が発生したプロセッサコア上で動作していたＡＰのデータが、障害発生プロセッサコア上のキャッシュに残存しており、そのキャッシュ上のデータをリカバリ処理するプロセッサコア上のキャッシュに移動するために多大な処理時間を要する。

さらに、特開平３−７３０３３号公報に記載の方法では、障害が発生したプロセッサコアとは別のハードウェア(公報では診断装置)によって障害情報を記憶する。障害情報の収集は、障害が発生したプロセッサコア(公報では処理装置)によって行われ、ハードウェア(診断装置)に障害情報を送信するため、障害情報の収集中は、次に動作すべきＡＰを動作させることができない。また、本方法では、障害情報を記録するために特別なハードウェア(公報では診断装置)が必要となる。

さらに、これら方法では、各プロセッサに同様な機能を持たせる構成で動作し、障害処理も各プロセッサ毎に固有な処理を行うことや、複数のＯＳ（以下ＯＳと称す）が動作していることを想定していないため、プロセッサコアに異なる機能を動作させるために、異なるＯＳを搭載するような情報処理装置に使用する場合、それぞれのＯＳ毎に、障害処理を分けて構成させる必要がある。

この発明は、上記のような問題を解決するためになされたもので、複数のプロセッサコアを持ったハードウェア構成を備え、その上で複数のＯＳおよびＡＰが動作している情報処理装置において、１つのプロセッサコアを障害処理専用プロセッサコアとし、それ以外のプロセッサコア上のＯＳは、初期化時に、自身の障害処理手段を障害処理専用プロセッサコアに登録し、１つのプロセッサコア上で動作しているＡＰに障害が起きた場合に、障害が発生したプロセッサコア上のＯＳは、別のＡＰを動作させるために最低限待避すべきハードウェア情報（汎用レジスタなど）のみ保存した後、障害を発生させたＡＰをスケジューリング対象外（停止状態）とし、障害処理用プロセッサコアに障害が発生したことを通知した後、障害が発生したプロセッサコアは、即座に次に動作すべきＡＰをスケジューリング対象とし、障害処理用プロセッサコアは障害が発生したプロセッサコアからの通知された障害発生ＡＰの情報を元に、障害情報の収集／記録、および障害に対する対処の決定をした後、障害が発生したプロセッサコアに障害対処処理が完了したことを通知し、その通知を受けた障害発生プロセッサは障害が発生したＡＰの動作状態を削除するようにすることで、障害が発生したプロセッサ上で次に動作すべきＡＰを迅速に動作させることができ、かつ、複数のＯＳ構成でも１つの構成で障害処理ができる、情報処置装置の障害処理システムを得ることを目的とする。

また、この発明は、障害処理専用プロセッサコア以外のプロセッサコア上のＯＳは、初期化時に、自身の障害処理手段のアドレスを障害処理専用プロセッサに登録し、ＡＰに障害が起きた場合に、障害が発生したプロセッサコアは、障害が発生したＡＰを停止するとともに、障害処理専用プロセッサに、ＡＰが動作していたアドレス空間情報を通知し、障害処理専用プロセッサは、そのアドレス空間情報を元に、障害発生プロセッサコアで動作していた障害発生ＡＰのアドレス空間で動作するように自身のアドレス空間を切り替え、登録されていた障害処理手段を実行し、障害情報の収集および情報の保存を行いうようにすることで、障害が発生したプロセッサ上で次に動作すべきＡＰを迅速に動作させることができ、かつ、複数のＯＳ構成でも１つの構成で障害処理ができる、情報処置装置の障害処理システムを得ることを目的とする。

また、この発明は、障害発生プロセッサコアから障害処理用プロセッサコアに障害発生を通知する際、障害情報を収集すべきメモリ領域の情報を付加することで、障害が発生したプロセッサ上で次に動作すべきＡＰを迅速に動作させることができ、かつ、複数のＯＳ構成でも１つの構成で障害処理ができる、情報処置装置の障害処理システムを得ることを目的とする。

また、この発明は、ＡＰがメモリを共有できる共有メモリに対し、障害発生時に、障害が発生したＡＰが使用している共有メモリを書込み禁止にし、他ＡＰが書き込み操作した場合、トラップを発生させるようにし、障害処理中に他ＡＰにて書込みが発生した場合は、書込みを行おうとしたＡＰに対し、書込みを行おうとした領域のコピーを用意し、そこに書込みを実施させるようにすることで、共有メモリを障害発生時の状態に保ちつつ、障害が発生したプロセッサ上で次に動作すべきＡＰを迅速に動作させることができ、かつ、複数のＯＳ構成でも１つの構成で障害処理ができる、情報処置装置の障害処理システムを得ることを目的とする。

また、この発明は、各プロセッサコアに障害処理用の手段を設け、メモリ上に待ちキューを備え、各プロセッサコアが、自身ですべき処理が何もないときに、待ちキューに自身の情報を登録し、何らかの処理が発生した場合に待ちキューから自身の情報を削除するようにし、障害が発生したプロセッサは、待ちキューにつながれているプロセッサコアの情報を元に、障害処理が可能なプロセッサコアに障害が発生したことを通知し、通知されたプロセッサコアは、自身の持っている障害処理用の手段を用いて、障害発生プロセッサで動作していたＡＰの障害情報の収集／記録、および障害に対する対処を行うようにすることで、障害が発生したプロセッサ上で次に動作すべきＡＰを迅速に動作させることができ、かつ、複数のＯＳ構成でも１つの構成で障害処理ができる、情報処置装置の障害処理システムを得ることを目的とする。

この発明に係る情報処理装置の障害処理システムは、メモリを共有し、夫々ＯＳが動作する複数のプロセッサコアを備え、上記各ＯＳ上で複数のＡＰが動作する情報処理装置の障害処理システムであって、
上記複数のプロセッサコアの何れか１つを、
他プロセッサコア上のＯＳに対する障害処理手段を登録する手段と、
他プロセッサコア上のＯＳに対する障害処理手段を登録する領域と、
他プロセッサコアからの通知により、そのプロセッサコアに対応した障害処理手段を起動する手段を備え、他プロセッサコアの各ＯＳ障害を専用に処理する障害処理専用プロセッサコアとし、
他プロセッサコア上のＯＳは、
障害処理専用プロセッサコア上で自ＯＳの障害処理を実施するため、ＯＳ初期化時に、自ＯＳの障害処理を実施する手段を障害処理専用プロセッサコアに登録依頼する手段と、
自ＡＰに障害が発生した際、障害発生ＡＰを停止し、障害処理専用プロセッサコアに障害発生ＡＰを通知するとともに、他ＡＰに動作を切替え、障害処理専用プロセッサコアからの障害処理完了通知後、障害発生ＡＰを再開または削除する手段を備える。

この発明による情報処理装置の障害処理システムによれば、ＡＰの障害発生時に障害が発生したＡＰを停止した後、障害が発生したＡＰが動作していたプロセッサコアとは別の障害処理専用のプロセッサコアにて障害情報の収集・記録・対処を行うようにし、障害情報の収集・記録・対処をしている間、障害が発生したＡＰが動作していたプロセッサコアでは、別のＡＰを動作できるようにしたので、障害が発生したプロセッサコア上で次に動作すべきＡＰを迅速に動作させることができる。
また、各エラー毎で異なる処理を、障害処理専用のプロセッサコアで処理し、障害が発生したプロセッサでは、障害検出・ＡＰ停止など処理時間が固定化された処理のみを行うようにしたことで、障害発生後の所定時間に別のＡＰが動作することができ、ＡＰの所定時間による応答性が確保できる。
さらに、各プロセッサコア内のＯＳ初期化時に、ＯＳ毎に固有な障害処理を、障害処理専用プロセッサコア内に登録するようにしたので、障害処理専用プロセッサコア上のソフトウェアが各ＯＳに依存することなく、複数のＯＳの障害処理を行うことができる。

実施の形態１．
以下、この発明の実施の形態１を図を用いて説明する。図１は、この実施の形態１における情報処理装置のハードウェア（Ｈ／Ｗ）構成図である。図中、１、２、３が演算処理を行うプロセッサコアであり、お互いが、バス４で結合される。また、バス４を通して、ＯＳのコードやデータ、およびＡＰのコードやデータ、およびヒープ／スタックを保持するメモリ５や、ＯＳやＡＰからのメッセージを出力するコンソール６、ＯＳおよびＡＰプログラムや設定ファイルを格納するハードディスク装置（ＨＤＤ）７、およびプロセッサコアのレジスタ情報や障害情報を、情報処理装置の再起動後でも保持しつづけるためのバックアップメモリ８が結合される。プロセッサコア１、プロセッサコア２、プロセッサコア３には、それぞれ、演算処理を行う演算処理部９（プロセッサコア１）、１０（プロセッサコア２）、１１（プロセッサコア３）、メモリ５の内容および演算処理部の処理結果を一時的に保持しておくキャッシュ１２（プロセッサコア１）、１３（プロセッサコア２）、１４（プロセッサコア３）、および、各プロセッサコア間で通信を行うためのプロセッサ間通信機能１５（プロセッサコア１）、１６（プロセッサコア２）、１７（プロセッサコア３）が存在する。

プロセッサ間通信機能については、プロセッサコアに割込みを通知する方法や、メモリ５を介して、通信したい（通信元）プロセッサコアが通信先プロセッサコアの参照するメモリ領域に印をつけ、通信先プロセッサがそれを参照することにより、通知を把握する方法などが利用される。また、プロセッサコア１、２、３には、メモリ５をアドレス空間として論理的に分割することができるＭＭＵ（Memory Management Unit）１８、１９、２０を備えている。ＯＳは、このＭＭＵを使用することで、各ＡＰのアドレス空間を独立して配置することが可能となり、各ＡＰはお互いを干渉することなく、メモリアクセスすることが可能になっている。この実施の形態では、３つのプロセッサコアを図示しているが、３つである必要はなく、２つ以上のプロセッサコアでも、動作そのものに変更はない。

図２は、図１で示したＨ／Ｗ構成に対する、ソフトウェア（Ｓ／Ｗ）の構成を示す図である。図中、プロセッサコア１にはＯＳ２１と、ＯＳ２１上で動作するＡＰ２２、ＡＰ２３が動作する。同様にプロセッサコア３には、ＯＳ２４と、ＯＳ２４上で動作するＡＰ２５、およびＡＰ２６が動作する。また、ＯＳ２１、ＡＰ２２、ＡＰ２３、およびＯＳ２４、ＡＰ２５、ＡＰ２６のコード／データ、およびヒープ／スタック領域はメモリ５上に存在する。メモリ５上は、ＯＳ２１が使用するＯＳ２１用領域２７と、ＯＳ２４が使用するＯＳ２４用領域２８とに用途が区切られている。ＯＳ２１用領域２７内には、ＯＳ２１上で動作するＡＰ２２のコード／データおよびヒープ／スタック領域であるＡＰ情報領域２９と、ＯＳ２１上で動作するＡＰ２３のコード／データおよびヒープ／スタック領域であるＡＰ情報領域３０が存在する。また、ＯＳ２４用領域２８内には、ＯＳ２４上で動作するＡＰ２５のコード／データおよびヒープ／スタック領域であるＡＰ情報領域３１と、ＯＳ２４上で動作するＡＰ２６のコード／データおよびヒープ／スタック領域であるＡＰ情報領域３２が存在する。そして、ＨＤＤ７上にはＡＰに障害が発生した場合のＡＰ情報を保持するコアファイル領域４１が、バックアップメモリ８には、ＡＰに障害が発生した場合に動作していたプロセッサコアに関する障害情報および情報処理装置全体の情報を保持するエラー情報格納域４２が存在する。プロセッサコア２には、障害処理を行うソフトウェアが存在する。

プロセッサコア１およびプロセッサコア３にあるＯＳ２１、およびＯＳ２４には、それぞれのプロセッサコア上で動作するＡＰに障害が発生した場合に、障害を検知し、対処する手段が存在する。そして、プロセッサコア２には、他プロセッサコアからの指示により障害情報を収集・記録する手段が存在する。プロセッサコア１上のＯＳ２１には、ＯＳの初期化処理を行うＯＳ初期化手段３３と、障害発生時にＯＳ２１に対応した障害処理を他プロセッサコア上で行うための障害処理手段３４、ＡＰの障害を検出する障害検出手段３５と、ＡＰの動作を切り替えるためのプロセス切替手段３６が存在する。同様にプロセッサコア３上のＯＳ２４にもＯＳ初期化手段３７、障害処理手段３８、障害検出手段３９、プロセス切替手段４０が存在する。ＯＳ２１およびＯＳ２４に存在する同じ名前の手段は、それぞれ同じ機能を有している。

一方、プロセッサコア２上には、他プロセッサコアで動作するＯＳに対応する障害処理手段の登録処理を行う障害処理登録手段４３と、他プロセッサコアからの指示により障害処理手段を起動する障害管理手段４４が存在するとともに、他プロセッサコア上のＯＳに対応する障害処理手段を格納するための登録領域４５が存在する。なお、この実施の形態では、プロセッサコア２に障害情報を収集・記録する機能が配置されているが、これら機能はプロセッサコアに依存しないため、他のプロセッサコアにこの機能が存在しても同じ意味を持つ。また、プロセッサコア２ではＯＳの記載がないが、ＯＳ内の機能、またはＡＰの機能にて、これら収集・記録機能を代替しても、同じ効果を得ることができる。

次に、この実施の形態における情報処理装置のＯＳ初期化時の動作について、図３の矢印および図４のフローチャートを用いて説明する。
まず、プロセッサコア１にＨ／Ｗリセットが掛かり、ＯＳ２１が起動されると、ＯＳ初期化手段３３が動作する。プロセッサコア１のＯＳ初期化手段３３は、ＯＳ内の様々な機能の初期化を行うと共に、ＯＳ２１内にある障害処理手段３４の登録をプロセッサコア２に依頼する(図３および図４のＳ１０１）。この登録依頼処理は、プロセッサコア１およびプロセッサコア２内のプロセッサ間通信機能（図１の１５、１６）を用いて行われる。プロセッサコア１での処理は以上となる。

プロセッサコア２は、起動後、障害処理登録手段４３が起動し、他プロセッサコアからの通知を待つ（図４のＳ１０２）。他プロセッサコアからの通知がない場合は、再度通知を待つ（Ｓ１０２のＮ）。他プロセッサコアから通知があった場合（Ｓ１０２のＹ）、依頼されたプロセッサコア１から障害処理手段３４の内容を受信し、登録領域４５内に障害処理手段３４’として格納する（図３および図４のＳ１０３）。そして再度、他プロセッサからの通知を待つ(Ｓ１０２）。このようにして、プロセッサコア２内の登録領域４５には、他プロセッサコア上で動作する各ＯＳに対応した障害処理手段が格納されることになる。障害処理手段の受信については、依頼元プロセッサコアがメモリ５に障害処理手段のデータを格納し、それをプロセッサコア２が参照する方法や、各プロセッサコアのプロセッサコア間通信機能（図１の１５、１６、１７）にて障害処理手段のデータを送信するようにする方法が考えられる。なお、上記実施の形態では、プロセッサコア１を対象に説明したが、これはプロセッサコア３の場合も同様であり、プロセッサコア３にてＯＳ２４内にある障害処理手段３８の登録をプロセッサコア２に依頼することで、プロセッサコア２内の障害処理登録手段４３が障害処理手段３８”を登録領域４５に格納する。
この実施の形態では、プロセッサコア２の障害処理登録手段４３が、他プロセッサコアからの通知を待っているように記載しているが、これを割込みベースにしても動作は同じである。この場合、プロセッサコア２にて他の処理を行っている最中に、プロセッサ間通信機能（図１の１６）にて割込みが発生し、その割込み処理にて障害処理登録手段４３が起動し、登録処理が実施された後、プロセッサコア２は、割込みが発生した時に行っていた処理に戻る。以上がこの実施の形態における情報処理装置のＯＳ初期化時の動作である。

次に、この実施の形態における情報処理装置の障害発生時の動作について、図５内の矢印および図６のフローチャートを用いて説明する。この実施の形態では、プロセッサコア１上で動作するＡＰ２２に障害が発生した場合の例で説明する。
まず、ＡＰ２２の動作中に障害が発生すると、プロセッサコア１上で例外が発生し、ＯＳ２１内の障害検出手段３５が、その例外を検出する（図５、図６のＳ１１１）。そして障害検出手段３５は、最低限のレジスタ情報をメモリ５内に保存した後、障害が発生したＡＰ２２を停止させるためにプロセス切替手段３６に通知する（図５、図６のＳ１１２）。

障害検出手段３５により通知されたプロセス切替手段３６は、障害が発生したＡＰ２２の実行を停止する（図５、図６のＳ１１３）。これは、ＡＰ２２が動作していたプロセスをスケジューリング対象から外し、同プロセスの状態を停止状態に移行することを意味し、プロセスそのものを削除することはこの時点ではしない。プロセスそのものを削除しないことにより、ＡＰ２２が使用していたメモリ５内のＡＰ情報領域２９がそのまま残存し、これをプロセッサコア２上から参照することが可能となる。

次に障害検出手段３５は、プロセッサ間通信機能（図１の１５）を利用して、障害を処理するプロセッサコア２に通知する（図５、図６のＳ１１４）。この時、障害が発生したＡＰ２２の情報や保存したレジスタ情報などが付加される。これら情報については、プロセッサコア２への通知時にメッセージ情報として付加する方法や、メモリ５上の特定領域に書き込む方法が考えられる。そして障害処理手段３４は、プロセス切替手段３６を介して、他ＡＰへの切替を行う。プロセス切替手段３６は、ＯＳ２１内のプロセス情報を参照し、動作可能なＡＰ２３を抽出し、ＡＰ２３を動作可能（ＲＵＮ状態）にする（図５、図６のＳ１１５）。これにより以降、プロセッサコア１上ではＡＰ２３が動作する（図６のＳ１１６）。

プロセッサコア２では、障害管理手段４４が動作しており、他プロセッサからの通知があるかチェックしている（図６のＳ１１７）。Ｓ１１４にて、プロセッサコア１からプロセッサコア２に割込みが通知されると、プロセッサコア２のプロセッサ間通信機能（図１の１６）が、その割込みを検出し、障害管理手段４４に通知する（図５、図６のＳ１１７）。障害管理手段４４では、Ｓ１１７にてその通知をチェックしており、通知があれば（Ｓ１１７のＹ）、通知元プロセッサコアに対応する障害処理手段を登録領域４５内から見つけ出し、その手段を起動する（図５、図６のＳ１１８）。

この実施の形態では、プロセッサコア１から通知されたので、登録領域４５内の障害処理手段３４’が起動される。この障害処理手段３４’は、プロセッサコア１内のＯＳ２１用のものであり、ＯＳ２１にあわせた障害処理が可能となる。障害処理手段３４’は、まず、通知にて付加されたＡＰ２２の情報を元に、メモリ５のＯＳ２１用領域２７内のＡＰ情報領域２９を探し、その中にある情報からエラーの発生種類（ページフォルト、０割り算等）や、発生箇所（ＯＳ内／ＡＰ内）、エラー発生時のレジスタ情報等を収集する（図５、図６のＳ１１９）。

次に障害処理手段３４’は、収集されたＡＰ２２の障害情報を元にエラー原因の特定および、それに伴いプロセッサコア１の動作を継続動作させるか、それとも、そのエラーが継続できない障害でプロセッサコア１をシステムダウン（停止または再起動）にすべきかを判断する（図６のＳ１２０）。システムダウンするケースとしては、障害発生の箇所がＡＰ２２が呼び出したＯＳ２１内で発生したエラーでＯＳ復帰ができないものや、ＣＰＵ内部エラーが発生した場合などが挙げられる。そして障害処理手段３４’は、特定されたエラー原因や継続動作またはシステムダウン動作遷移情報、および収集された障害情報を、コンソール６に表示し、使用者に障害が発生したことを通知するとともに、バックアップメモリ８内のエラー情報格納域４２に、これら情報を記録し、障害発生後も使用者が障害発生情報を参照できるようにする（図５、図６のＳ１２１）。

次に障害処理手段３４’は、プロセッサコア１の対処としてシステムダウンすべきか否か判断する（図６のＳ１２２）。システムダウンすべき場合（Ｓ１２２のＹ）は、プロセッサコア１を停止状態にさせた後、メモリ５内のＯＳ２１用領域２７の内容をディスクに書き込む（メモリダンプ）などした後、プロセッサコア１のリブート（Ｈ／Ｗリセット）を行う（図６のＳ１２３）。これにより、プロセッサコア１は初期状態に戻り、再度ＯＳ２１がブートされる。

Ｓ１２２にてシステムダウンしない場合（Ｓ１２２のＮ）、障害処理手段３４’は、特定されたエラー原因を元に、各エラーに対応した処理をおこなう（図６のＳ１２４）。これは、例えば０割り算によるエラーであれば、次にＡＰ２２が実行される場合は、０割り算のシグナルハンドラ（エラー発生に伴い呼び出される関数）を呼び出すようにＡＰ情報領域２９内のＡＰ２２のスタックを操作したり、セグメンテーションフォルトによるエラーであれば、コアファイル４１を作成する準備を行う。そして、障害処理手段３４’は、コアファイル４１を作成するようなエラーである場合に、コアファイル作成処理を行う（図５、図６のＳ１２５）。この時、障害処理手段３４’は、ＡＰ情報領域２９の内容をＨＤＤ７内のコアファイル４１に書き出す。コアファイル４１の作成が終了すると、障害処理手段３４’は、ＡＰ２２を再開させるために停止処理解除要求をプロセッサコア１に通知する（図５、図６のＳ１２６）。これは、プロセッサ間通信機能（図１の１６）を利用して、プロセッサコア１に割込みを通知することで行われる。この時、ＡＰ２２を継続動作させるか、削除すべきかの情報が付加される。

Ｓ１１６にてプロセッサコア１上でＡＰ２３が動作している間に、プロセッサコア２での障害情報の収集および記録が終了し、Ｓ１２６にてプロセッサコア２からプロセッサコア１に対しＡＰ２２の停止処理解除要求が実施されると、プロセッサコア１のプロセッサ間通信機能（図１の１５）がその割込みを受信し、ＯＳ２１内のプロセス切替手段３６を起動する（図６のＳ１２７）。プロセス切替手段３６は、通知にて付加されたＡＰ２２を継続動作させるか、削除すべきかの情報を元に、ＡＰ２２の再開または終了を処理する（図５、図６のＳ１２８）。継続動作させる場合は、ＡＰ２２が動作していたプロセスをスケジューリング対象に戻し、終了させる場合は、ＡＰ２２が動作していたプロセスを削除する処理を行う。以上がこの実施の形態における情報処理装置の障害発生時の動作である。

この実施の形態１による情報処理装置の障害処理システムでは、ＡＰの障害発生時に、障害が発生したＡＰを停止した後、障害が発生したＡＰが動作していたプロセッサコアとは別のプロセッサコアにて障害情報の収集・記録・対処を行うようにし、障害情報の収集・記録・対処をしている間、障害が発生したＡＰが動作していたプロセッサコアでは、別のＡＰを動作できるようにしたので、障害が発生したプロセッサコア上で次に動作すべきＡＰを迅速に動作させることができる、情報処理装置の障害処理システムを得ることができる。

また、この実施の形態では、各エラーごとで異なる処理を、障害が発生したプロセッサコアとは別のプロセッサコアで処理し、障害が発生したプロセッサでは、障害検出・レジスタ保存・ＡＰ停止など処理時間が固定化された処理のみを行うようにしたことで、障害が発生しても、一定時間に別のＡＰが動作することができ、ＡＰの一定時間による応答性が確保できる情報処理装置の障害処理システムを得ることできる。

さらに、この実施の形態では、各プロセッサコア内のＯＳ初期化時に、ＯＳ毎に固有な障害処理を、障害処理専用プロセッサコア内に登録するようにしたので、障害処理専用プロセッサコア上のソフトウェアが各ＯＳに依存することなく、複数のＯＳの障害処理を行うことができる、障害処理装置の障害処理システムを得ることができる。

実施の形態２．
この発明の他の実施の形態における情報処理装置の障害処理システムについて説明する。実施の形態２では、情報処理装置のＨ／Ｗ構成は実施の形態１と同じであり、図１で示される。図７は、図１で示したＨ／Ｗ構成に対する、ソフトウェア（Ｓ／Ｗ）の構成を示す図である。実施の形態２では、実施の形態１のＳ／Ｗ構成におけるＯＳと内部の各手段、ＡＰおよびプロセッサコア２上の各手段と登録領域は、ほぼ同じような機能を持つ。図中、プロセッサコア１にはＯＳ２１と、ＯＳ２１上で動作するＡＰ２２、およびＡＰ２３を備え、プロセッサコア３にはＯＳ２４と、ＯＳ２４上で動作するＡＰ２５、およびＡＰ２６を備える。ＯＳ２１、およびＯＳ２４には、それぞれのプロセッサコア上で動作するＡＰに障害が発生した場合に、障害を検知し、対処する手段が存在する。そして、プロセッサコア２には、他プロセッサコアからの指示により障害情報を収集・記録する手段が存在する。

プロセッサコア１上のＯＳ２１には、ＯＳの初期化処理を行うＯＳ初期化手段３３と、障害発生時にＯＳ２１に対応した障害処理を他プロセッサコア上で行うための障害処理手段３４、ＡＰの障害を検出する障害検出手段３５と、ＡＰの動作を切り替えるためのプロセス切替手段３６が存在する。同様にプロセッサコア３上のＯＳ２４にもＯＳ初期化手段３７、障害処理手段３８、障害検出手段３９、プロセス切替手段４０が存在する。ＯＳ２１およびＯＳ２４に存在する同じ名前の手段は、それぞれ同じ機能を有している。

一方、プロセッサコア２上には、他プロセッサコアで動作するＯＳに対応する障害処理手段の登録処理を行う障害処理登録手段４３と、他プロセッサコアからの指示により障害処理手段を起動する障害管理手段４４が存在するとともに、他プロセッサコア上のＯＳに対応する障害処理手段が登録される登録領域４５が存在する。そして、ＨＤＤ７上にはＡＰに障害が発生した場合のＡＰ情報を保持するコアファイル領域４１が、また、バックアップメモリ８には、ＡＰに障害が発生した場合に動作していたプロセッサコアに関する障害情報および情報処理装置全体の情報を保持するエラー情報格納域４２が存在する。プロセッサコア２には、障害処理を行うソフトウェアが存在する。

ＯＳ２１、ＡＰ２２、ＡＰ２３、およびＯＳ２４、ＡＰ２５、ＡＰ２６のコード／データ、およびヒープ／スタック領域はメモリ５上に存在する。メモリ５上には、ＯＳ２１が使用するＯＳ２１用領域２７と、ＯＳ２４が使用するＯＳ２４用領域２８、およびプロセッサコア２が使用するプロセッサコア２用領域４９とに用途が区切られている。
ＯＳ２１用領域２７内には、ＯＳ２１上で動作するＡＰ２２のコード／データおよびヒープ／スタックを格納しているＡＰ２２テキスト／データ領域と、ＯＳ２１のコード／データおよびヒープ／スタックを格納しているＯＳテキスト／データ領域が存在し、それらは、ＡＰ２２アドレス空間５０として、ページテーブル５２を介して結合されている。ページテーブル５２は、メモリ５上のＡＰ２２テキスト／データ領域およびＯＳテキスト／データ領域を論理的に連続したアドレス空間にマッピングするための空間配置テーブルである。このページテーブル５２がプロセッサコア１のＭＭＵ１８に設定されることにより、プロセッサコア１のアドレス空間は、ＡＰ２２アドレス空間５０にマッピングされ、ＡＰ２２のテキスト／データ領域が参照できることで、ＡＰ２２が動作可能となる。

また、ＡＰ２２からシステムコール呼び出しでＯＳ２１が呼び出されても、ＡＰ２２アドレス空間５０にはＯＳテキスト／データ領域が含まれているので、ＯＳ２１の動作が可能となる。ＯＳ２１用領域２７には、同様にＯＳ２１上で動作するＡＰ２３のコード／データおよびヒープ／スタックを格納しているＡＰ２３テキスト／データ領域が存在し、これは、ＡＰ２３アドレス空間５１として、ページテーブル５３を介し、ＯＳテキスト／データ領域と結合されている。ＯＳテキスト／データ領域はＯＳ２１用領域２７内においては１つだけであるが、ページテーブル５２および５３の空間配置テーブルにて、双方とも参照するように設定されており、これにより、ＡＰ２２アドレス空間５０およびＡＰ２３アドレス空間５１双方からＯＳテキスト／データ領域を共有する形となっている。ＯＳテキスト／データ領域はＯＳ２１のコード／データおよびヒープ／スタックを格納しているので、この中に、ＯＳ２１内の各手段も格納されており、障害処理手段３４も、この領域で参照可能になっている。

同様に、ＯＳ２４用領域２８内には、ＯＳ２４上で動作するＡＰ２５のコード／データおよびヒープ／スタックを格納しているＡＰ２５領域と、ＯＳ２４のコード／データおよびヒープ／スタックを格納しているＯＳ領域が存在し、それらは、ＡＰ２５アドレス空間５４として、ページテーブル５６を介して結合されている。このページテーブル５６がプロセッサコア３のＭＭＵ２０に設定されることにより、プロセッサコア３のアドレス空間は、ＡＰ２５アドレス空間５４にマッピングされ、ＡＰ２５領域が参照できることで、ＡＰ２５が動作可能となる。

また、ＡＰ２５からシステムコール呼び出しでＯＳ２４が呼び出されても、ＡＰ２５アドレス空間５４にはＯＳ領域が含まれているので、ＯＳ２４の動作が可能となる。ＯＳ２４用領域２８には、同様にＯＳ２４内で動作するＡＰ２６のコード／データおよびヒープ／スタックを格納しているＡＰ２６領域が存在し、これは、ＡＰ２６アドレス空間５５として、ページテーブル５７を介し、ＯＳ領域と結合されている。ＯＳ領域はＯＳ２４領域２８内においては、１つだけあるが、ページテーブル５６および５７の空間配置テーブルにて、双方とも参照するように設定されており、これにより、ＡＰ２５アドレス空間５４およびＡＰ２６アドレス空間５５双方からＯＳ領域を共有する形となっている。ＯＳ領域はＯＳ２４のコード／データおよびヒープ／スタックを格納しているので、この中に、ＯＳ２４内の各手段も格納されており、障害処理手段３９も、この領域で参照可能になっている。

プロセッサコア２用領域４９内には、プロセッサコア２上で動作するソフトウェアのコード／データおよびヒープ／スタックを格納しているテキスト／データ領域５８が存在し、それらはアドレス空間５８としてページテーブル５９を介して結合されている。テキスト／データ領域５８には、プロセッサコア２上で動作するソフトウェアを格納しているため、障害処理登録手段４３、障害管理手段４４および登録領域４５は、この領域で参照可能になっている。また、ページテーブル５９がプロセッサコア２のＭＭＵ１９に設定されることにより、プロセッサコア２のアドレス空間は、アドレス空間（テキスト／データ領域）５８にマッピングされ、プロセッサコア２上のソフトウェアのテキスト／データ領域が参照できることで、障害処理登録手段４３、障害管理手段４４が動作可能となり、登録領域４５も、これら各手段で参照可能になる。

次に、この実施の形態における情報処理装置のＯＳ初期化時の動作について、図８の矢印および図９のフローチャートを用いて説明する。まず、プロセッサコア１にＨ／Ｗリセットが掛かり、ＯＳ２１が起動されると、ＯＳ初期化手段３３が動作する。プロセッサコア１のＯＳ初期化手段３３は、ＯＳ内の様々な機能の初期化を行うと共に、プロセッサコア２にＯＳ２１内にある障害処理手段３４のアドレス、すなわちＯＳ２１用領域２７内のＯＳテキスト／データ領域内にある障害処理手段テキスト／データ領域のアドレスの登録を依頼する（図８、図９のＳ２０１）。

このアドレスはページテーブル５２またはページテーブル５３を介してアクセス可能な論理空間アドレスを登録依頼する。ＯＳテキストデータ領域は、ページテーブル５２またはページテーブル５３を介した論理空間アドレス上では、同じアドレスに配置されており、どちらのページテーブルを参照しても、同じ位置で障害処理手段が参照可能になっている。登録依頼処理は、プロセッサコア１およびプロセッサコア２内のプロセッサコア通信機能（図１の１５、１６）を用いて行われる。プロセッサコア１でのＯＳ初期化時の処理は以上となる。

プロセッサコア２は、起動後、障害処理登録手段４３が起動し、他プロセッサコアからの通知を待つ（図９のＳ２０２）。他プロセッサコアから通知がない場合は、再度通知を待つ（Ｓ２０２のＮ）。他プロセッサコアから通知があった場合（Ｓ２０２のＹ）、依頼されたプロセッサコア１から障害処理手段３４のアドレスを受信し、登録領域４５内に障害処理手段アドレス６０として格納する（図８、図９のＳ２０３）。そして再度、他プロセッサからの通知を待つ(Ｓ２０２）。このようにして、プロセッサコア２内の登録領域４５には、他プロセッサコア上で動作する各ＯＳにある障害処理手段のアドレスが格納されることになる。障害処理手段のアドレス情報の受信については、依頼元プロセッサコアがメモリ５に障害処理手段アドレス情報のデータを格納し、それをプロセッサコア２が参照する方法や、各プロセッサコアのプロセッサコア間通信機能（図１の１５、１６、１７）にて障害処理手段アドレス情報のデータを送信するようにする方法が考えられる。

なお、上記例では、プロセッサコア１を対象に説明したが、これはプロセッサコア３の場合も同様であり、プロセッサコア３にてＯＳ２４内にある障害処理手段３８のアドレスの登録をプロセッサコア２に依頼することで、プロセッサコア２内の障害処理登録手段４３が障害処理手段３８のアドレス６１を登録領域４５に格納する。この実施の形態では、プロセッサコア２の障害処理登録手段４３が、他プロセッサコアからの通知を待っているように記載しているが、これを割込みベースにしても動作は同じである。この場合、プロセッサコア２にて他の処理を行っている最中に、プロセッサ間通信機能（図１の１６）にて割込みが発生し、その割込み処理にて障害処理登録手段４３が起動し、登録処理が実施された後、プロセッサコア２は、割込みが発生した時に行っていた処理に戻る。
以上がこの実施の形態における情報処理装置のＯＳ初期化時の動作である。

次に、この実施の形態における情報処理装置の障害発生時の動作について、図１０のフローチャートおよび図１１、図１２、図１３、を用いて説明する。
この実施の形態では、プロセッサコア１上で動作するＡＰ（ＡＰ）２２に障害が発生した場合の例で説明する。まず、プロセッサコア１ではＡＰ２２が動作している（図１０、Ｓ２１０）。この時の動作状況を示すのが図１１である。ＡＰ２２が動作している時、プロセッサコア１のＭＭＵ１８は、ＯＳ２１用領域２７内のページテーブル５２を参照するように設定されている。これにより、プロセッサコア１は、ＡＰ２２アドレス空間５０をアドレス空間として動作しており、この中にあるＡＰ２２テキスト／データ領域を参照し、ＡＰ２２内のコードを実行している。
一方、プロセッサコア２のＭＭＵ１９は、プロセッサコア２用領域４９内のページテーブル５９を参照するように設定されている。これにより、プロセッサコア２は、アドレス空間（テキスト／データ領域）５８をアドレス空間として動作しており、この中にあるテキスト／データ領域を参照し、障害管理手段４４のコードを実行している。

ＡＰ２２の動作中に障害が発生すると、プロセッサコア１上で例外が発生し、ＯＳ２１内の障害検出手段３５が、その例外を検出する（図１０、図１２のＳ２１１）。この時、プロセッサコア１のＭＭＵ１８は、ＯＳ２１用領域のページテーブル５２が設定されており、プロセッサコア１はＡＰ２２アドレス空間５０内にあるＯＳテキスト／データ領域内に存在する障害検出手段３５に制御を移すことができる。障害検出手段３５は、最低限のレジスタ情報をメモリ５内に保存した後、障害が発生したＡＰ２２を停止させるためにプロセス切替手段３６に通知する（図１０、図１２のＳ２１２）。プロセス切替手段３６もＡＰ２２アドレス空間５０内のＯＳテキスト／データ領域に存在するので、そのまま制御が移すことができる。障害検出手段３５により通知されたプロセス切替手段３６は、障害が発生したＡＰ２２の実行を停止する（図１０、図１２のＳ２１３）。これは、ＡＰ２２が動作していたプロセスをスケジューリング対象から外し、同プロセスの状態を停止状態に移行することを意味し、プロセスそのものを削除することはこの時点ではしない。

また、プロセッサコア１はＡＰ２２アドレス空間５０を参照したままであり、ＭＭＵ１８はページテーブル５２をまだ参照している。プロセスそのものを削除しないことにより、ＡＰ２２が使用していたメモリ５内のＡＰ２２アドレス空間５０内の情報がそのまま残存し、これによりプロセッサコア２上から参照することが可能となる
次に障害検出手段３５は、プロセッサ間通信機能（図１の１５）を利用して、ＡＰ２２の障害発生を障害処理するプロセッサコア２に通知する（図１０、図１２のＳ２１４）。この時、障害が発生したＡＰ２２の情報や保存したレジスタ情報などが付加されるとともに、ページテーブル５２の情報も付加される。これら情報については、プロセッサコア２への通知時にメッセージ情報として付加する方法や、メモリ５上の特定領域に書き込む方法が考えられる。そして障害処理手段３４は、プロセス切替手段３６を介して、他ＡＰへの切替を行う。

プロセス切替手段３６は、ＯＳ２１内のプロセス情報を参照し、動作可能なＡＰ２３を抽出し、ＡＰ２３を動作可能（ＲＵＮ状態）にし、プロセッサコア１のＭＭＵ１８をＯＳ２１用領域のページテーブル５３を参照するように設定する（図１０、図１２のＳ２１５）。これにより、プロセッサコア１はＡＰ２３アドレス空間５１をアドレス空間として参照するようになる。ＯＳテキスト／データ領域は、ＡＰ２２アドレス空間５０、ＡＰ２３アドレス空間５１ともに同じアドレス上に存在するため、アドレス空間を切り替えても、ＯＳ２１内のコード／データは同じように扱うことができ、ＯＳ２１内の各手段もそのまま動作可能である。ＯＳ２１のプロセス切替手段３６は、切り替えられたＡＰ２３アドレス空間５１内にある、ＡＰ２３テキスト／データ領域内のＡＰ２３に制御を移すことにより、以降、プロセッサコア１上ではＡＰ２３が動作する（図１０のＳ２１６）。

プロセッサコア２では、障害管理手段４４が動作しており、他プロセッサからの通知があるかチェックしている（図１０のＳ２１７）。Ｓ２１４にて、プロセッサコア１からプロセッサコア２に割込みが通知されると、プロセッサコア２のプロセッサ間通信機能（図１の１６）が、その割込みを検出し、障害管理手段４４に通知する（図１０のＳ２１７）。障害管理手段４４では、Ｓ２１７にてその通知をチェックしており、通知があれば（Ｓ２１７のＹ）、通知元プロセッサコアに対応する障害処理手段のアドレスを登録領域４５内から見つけ出す。そして、通知元プロセッサから送られてきたページテーブル情報と障害処理手段のアドレスを元に、障害処理手段を起動する（図１０、図１２のＳ２１８）。

この実施の形態では、プロセッサコア１から通知されたので、登録領域４５内の障害処理手段アドレス６０が選択される。そして、プロセッサコア２のＭＭＵ１９を、プロセッサコア１から送られてきたページテーブル５２の情報を元に設定する。ページテーブル５２の情報は、メモリ５上にあり、プロセッサコア１でもプロセッサコア２でも同じように扱うことができる。これにより、プロセッサコア２は、ＡＰ２２アドレス空間５０にアドレス空間が切り替わる。そして、登録領域４５に登録されていた障害処理手段アドレス６０を元に、ＡＰ２２アドレス空間５０内にある、ＯＳ２１のコード／データが格納されているＯＳテキスト／データ領域内の、障害処理手段を起動する。これにより、プロセッサコア２にて障害処理手段３４が動作する。この障害処理手段３４は、ＯＳ２１用のものであり、ＯＳ２１にあわせた障害処理が可能となる。

プロセッサコア２で動作している障害処理手段３４は、まず、通知にて付加されたＡＰ２２の情報を元に、ＡＰ２２アドレス空間５０内にあるＡＰ２２テキスト／データ領域を探し、その中にある情報からエラーの発生種類（ページフォルト、０割り算等）や、発生箇所（ＯＳ内／ＡＰ内）、エラー発生時のレジスタ情報等を収集する（図１０、図１２のＳ２２０）。次にプロセッサコア２で動作している障害処理手段３４は、収集されたＡＰ２２の障害情報を元にエラー原因の特定および、それに伴いプロセッサコア１の動作を継続動作させるか、それとも、そのエラーが継続できない障害でプロセッサコア１をシステムダウン（停止または再起動）にすべきかを判断する（図１０のＳ２２１）。そしてプロセッサコア２で動作している障害処理手段３４は、特定されたエラー原因や継続動作またはシステムダウン動作遷移情報、および収集された障害情報を、コンソール６に表示し、使用者に障害が発生したことを通知するとともに、バックアップメモリ８内のエラー情報格納域４２に、これら情報を記録し、障害発生後も使用者が障害発生情報を参照できるようにする（図１０、図１２のＳ２２２）。

次にプロセッサコア２で動作している障害処理手段３４は、プロセッサコア１の対処としてシステムダウンすべきか否か判断する（図１０のＳ２２３）。システムダウンすべき場合（Ｓ２２３のＹ）は、プロセッサコア１を停止状態にさせ、メモリ５内のＯＳ２１用領域２７の内容をディスクに書き込む（メモリダンプ）などした後、プロセッサコア１のリブート（Ｈ／Ｗリセット）を行う（図１０のＳ２２４）。これにより、プロセッサコア１は初期状態に戻り、再度ＯＳ２１がブートされる。

Ｓ２２３にてシステムダウンしない場合（Ｓ２２３のＮ）、プロセッサコア２で動作している障害処理手段３４は、特定されたエラー原因を元に、各エラーに対応した処理をおこなう（図１０のＳ２２５）。これは、例えば０割り算によるエラーであれば、次にＡＰ２２が実行される場合は、０割り算のシグナルハンドラ（エラー発生に伴い呼び出される関数）を呼び出すようにＡＰ２２アドレス空間５０のＡＰ２２テキスト／データ領域内にあるＡＰ２２のスタックを操作したり、セグメンテーションフォルトによるエラーであれば、コアファイル４１を作成する準備を行う。そして、プロセッサコア２で動作している障害処理手段３４は、コアファイル４１を作成するようなエラーである場合に、コアファイル作成処理を行う（図１０、図１２のＳ２２６）。この時、障害処理手段３４は、ＡＰ２２アドレス空間５０のＡＰ２２テキスト／データ領域の内容をＨＤＤ７内のコアファイル４１に書き出す。

コアファイル４１の作成が終了すると、プロセッサコア２で動作している障害処理手段３４は、ＡＰ２２を再開させるために停止処理解除要求をプロセッサコア１に通知する（図１０、図１３のＳ２２７）。これは、プロセッサ間通信機能（図１の１６）を利用して、プロセッサコア１に割込みを通知することで行われる。この時、ＡＰ２２を継続動作させるか、削除すべきかの情報が付加される。その後、プロセッサコア２で動作している障害処理手段３４の処理は終了し、障害管理手段４４に復帰する（図１０、図１３のＳ２２８）。プロセッサコア２のＭＭＵ１９を、障害管理手段３４が動作するために設定していたページテーブル５２から、プロセッサコア２用領域にあるページテーブル５９に変更し、プロセッサコア２のアドレス空間が、ＯＳ２１用領域２７内のＡＰ２２アドレス空間５０から、プロセッサ２用領域４９のアドレス空間５８に切り替わることにより、アドレス空間（テキスト／データ領域）５８内にある障害管理手段４４に制御が戻る。制御が戻った障害管理手段４４は、他プロセッサからの通知がない場合のチェックに戻る（図１０のＳ２１７）。

Ｓ２１６にてプロセッサコア１上でＡＰ２３が動作している間に、プロセッサコア２での障害情報の収集および記録が終了し、Ｓ２２７にてプロセッサコア２からプロセッサコア１に対しＡＰ２２の停止処理解除要求が実施されると、プロセッサコア１のプロセッサ間通信機能（図１の１５）がその割込みを受信し、ＯＳ２１内のプロセス切替手段３６を起動する（図１０のＳ２２９）。プロセス切替手段３６は、通知にて付加されたＡＰ２２を継続動作させるか、削除すべきかの情報を元に、ＡＰ２２の再開または終了を処理する（図１０、図１３のＳ２３０）。継続動作させる場合は、ＡＰ２２が動作していたプロセスをスケジューリング対象に戻し、終了させる場合は、ＡＰ２２が動作していたプロセスを削除する処理を行う。以上がこの実施の形態における情報処理装置の障害発生時の動作である。

この実施の形態２による情報処理装置の障害処理システムでは、障害を処理するプロセッサコアに、他プロセッサコア上で動作する各ＯＳの障害処理手段のアドレスを登録し、プロセッサコアにて障害が発生した場合に、障害が発生したＡＰが動作していたアドレス空間を管理するページテーブル情報を障害を処理するプロセッサコアに渡し、障害を処理するプロセッサコアは、ページテーブル情報を元に、自身のＭＭＵをＡＰが動作していたアドレス空間に切り替えることで、障害を処理するプロセッサコアにてＡＰが動作していたアドレス空間で障害処理を行うことができるようにしたので、障害が発生したプロセッサコア上で次に動作すべきＡＰを迅速に動作させることができるとともに、障害処理専用プロセッサコアのソフトウェアが各ＯＳに依存することなく、複数のＯＳの障害処理を行うことができる、障害処理装置の障害処理システムを得ることができる。

なお、この実施の形態では、ＭＭＵにて仮想（論理）アドレス空間を切り替えるようなＯＳを用いて実施例を説明したが、ＭＭＵを持たない情報処理装置でも、同様な処理は可能である。この場合、各ＯＳ用領域および障害処理専用プロセッサコア用領域は、独立して配置される（各領域が同じアドレス上に存在すると、データが上書きされるため、動作はできない）ので、障害処理専用プロセッサコアの登録領域に登録される各ＯＳの障害処理手段アドレスも、それぞれ異なるアドレスになる。障害処理専用プロセッサコアは、通知されたプロセッサコアに対応した障害処理手段アドレスを実行することで、そのプロセッサコア上で動作しているＯＳの障害処理手段を実行することが可能であるとともに、ＡＰのテキスト／データ領域も、メモリ５上にて障害処理専用プロセッサコアから参照可能であるので、この実施の形態と同様な障害処理を行うことが可能となる。

実施の形態３．
この発明の他の実施の形態における情報処理装置の障害処理システムについて説明する。実施の形態３では、情報処理装置のＨ／Ｗ構成は実施の形態１と同じであり、図１で示される。図１４は、図１で示したＨ／Ｗ構成に対する、ソフトウェア（Ｓ／Ｗ）の構成を示す図である。図中、プロセッサコア１にはＯＳ２１と、ＯＳ２１上で動作するＡＰ２２、ＡＰ２３が動作する。同様にプロセッサコア３には、ＯＳ２４と、ＯＳ２４上で動作するＡＰ２５、およびＡＰ２６が動作する。また、ＯＳ２１、ＡＰ２２、ＡＰ２３、およびＯＳ２４、ＡＰ２５、ＡＰ２６のコード／データ、およびヒープ／スタック領域はメモリ５上に存在する。

メモリ５上は、ＯＳ２１が使用するＯＳ２１用領域２７と、ＯＳ２４が使用するＯＳ２４用領域２８とに用途が区切られており、ＯＳ２１用領域２７内には、ＯＳ２１上で動作するＡＰ２２のコード／データおよびヒープ／スタック領域であるＡＰ情報領域２９と、ＯＳ２１上で動作するＡＰ２３のコード／データおよびヒープ／スタック領域であるＡＰ情報領域３０、ＯＳ２１のコード／データおよびヒープ／スタック領域であるＯＳ内部情報領域７０が、ＯＳ２４用領域２８内には、ＯＳ２４上で動作するＡＰ２５のコード／データおよびヒープ／スタック領域であるＡＰ情報領域３１と、ＯＳ２４上で動作するＡＰ２６のコード／データおよびヒープ／スタック領域であるＡＰ情報領域３２、およびＯＳ２４のコード／データおよびヒープ／スタック領域であるＯＳ内部情報領域７１が存在する。

またメモリ５上には、障害情報が格納されている領域を示す収集領域情報７２も存在する。そして、ＨＤＤ７上にはＡＰに障害が発生した場合のＡＰ情報を保持するコアファイル領域４１が、バックアップメモリ８には、ＡＰに障害が発生した場合に動作していたプロセッサコアに関する障害情報および情報処理装置全体の情報を保持するエラー情報格納域４２が存在する。プロセッサコア２には、障害処理を行うソフトウェアが存在する。

プロセッサコア１上のＯＳ２１には、ＡＰの障害を検出する障害検出手段３５と、ＡＰの動作を切り替えるためのプロセス切替手段３６が存在する。同様にプロセッサコア３上のＯＳ２４にも障害検出手段３９、プロセス切替手段４０が存在する。ＯＳ２１およびＯＳ２４に存在する同じ名前の手段は、それぞれ同じ機能を有している。一方、プロセッサコア２上には、他プロセッサコアからの指示により障害情報の収集・対処・記録を管理する障害管理手段４４が存在する。なお、この実施の形態では、プロセッサコア２に障害情報を収集・記録する機能が配置されているが、これはプロセッサコアに依存しないため、他のプロセッサコアにこの機能が存在しても同じ意味を持つ。また、プロセッサコア２ではＯＳの記載がないが、ＯＳ内の機能、またはＡＰの機能にて、これら収集・記録機能を代替しても、同じ効果を得ることができる。

次に、この実施の形態における収集領域情報７２の内容を図１５を用いて説明する。収集領域情報７２の内容は、図１５に示すように、各領域毎にその領域がどの障害情報を保持しているかを示すタイプ格納部分と、収集する領域のアドレスを格納および領域のサイズを保持する部分、そして保存先を示す部分および保存先アドレスを示す部分が存在する。プロセッサコア２の障害管理手段４４は、収集した収集領域情報７２のタイプ情報からレジスタ情報がどこにあるか判断し、エラー原因の特定を行い、コアファイル保存領域がどこにあるか判断し、その保存先とアドレス情報から、収集した領域をコアファイル４１内の任意の位置に保存する。また、それ以外の領域については、コンソール６やエラー情報格納領域４２に内容を表示・記録する。

次に、この実施の形態における情報処理装置の障害発生時の動作について、図１６内の矢印および図１７のフローチャートを用いて説明する。この実施の形態では、プロセッサコア１上で動作するＡＰ２２に障害が発生した場合の例で説明する。まず、ＡＰ２２の動作中に障害が発生すると、プロセッサコア１上で例外が発生し、ＯＳ２１内の障害検出手段３５が、その例外を検出する（図１６、図１７のＳ３０１）。そして障害検出手段３５は、ＡＰを切り替えるために最低限必要なレジスタ情報をメモリ５内のＯＳ２１用領域２７内に保存するとともに、収集領域情報７２に障害情報として記録すべき情報のタイプおよび領域のアドレス／サイズ、保存先および保存先アドレスを設定する（図１６、図１７のＳ３０２）。ＯＳ２１用領域２７内に保存されるレジスタ情報は、ＯＳ２１内部情報７０に保存される。

また、収集領域情報７２に保存される領域は、ＯＳ２１内部情報７０に保存されたレジスタ情報や、コアファイルを保存するために必要なＡＰ情報領域２９全体の情報、そして、コンソール６やバックアップメモリ８内のエラー情報格納域４２に保存すべき、その他の情報（ＡＰ情報領域２９内のスタック情報やヒープ情報、ＡＰの変数情報など）について、タイプ（レジスタ情報、コアファイル情報等）とその情報のメモリ５上の位置（領域アドレス）とサイズ、および保存先のタイプと保存先デバイス内の保存位置（アドレス）が設定される。

レジスタ情報の保存および収集領域情報７２の設定が終了した後、障害情報対処手段３５は、障害が発生したＡＰ２２を停止させるためにプロセス切替手段３６に通知する（図１６、図１７のＳ３０３）。障害検出手段３５により通知されたプロセス切替手段３６は、障害が発生したＡＰ２２の実行を停止する（図１６、図１７のＳ３０４）。これは、ＡＰ２２が動作していたプロセスをスケジューリング対象から外し、同プロセスの状態を停止状態に移行することを意味し、プロセスそのものを削除することはこの時点ではしない。プロセスそのものを削除しないことにより、ＡＰ２２が使用していたメモリ５内のＡＰ情報領域２９がそのまま残存し、これをプロセッサコア２上から参照することが可能となる。

次に障害検出手段３５は、プロセッサ間通信機能（図１の１５）を利用して、障害発生を障害処理するプロセッサコア２に通知する（図１６、図１７のＳ３０５）。この実施の形態では、プロセッサコア２はメモリ５内の収集領域情報７２に従って情報収集を行うため、障害が発生したＡＰ２２の情報は通知する必要がない。そして障害処理手段３５は、プロセス切替手段３６を介して、他ＡＰへの切替を行う。プロセス切替手段３６は、ＯＳ２１内のプロセス情報を参照し、動作可能なＡＰ２３を抽出し、ＡＰ２３を動作可能（ＲＵＮ状態）にする（図１６、図１７のＳ３０６）。これにより以降、プロセッサコア１上ではＡＰ２３が動作する（図１７のＳ３０７）。

プロセッサコア２では、障害管理手段４４が動作しており、他プロセッサからの通知があるかチェックしている（図１７のＳ３０８）。Ｓ３０８にて、プロセッサコア１からプロセッサコア２に割込みが通知されると、プロセッサコア２のプロセッサ間通信機能（図１の１６）が、その割込みを検出し、障害管理手段４４に通知する（図１６、図１７のＳ３０９）。障害管理手段４４では、Ｓ３０８にてその通知をチェックしており、通知があると（Ｓ３０８のＹ）、障害管理手段４４は、まず、障害情報の収集を行う（図１６、図１７のＳ３１０）。障害管理手段４４は、収集領域情報７２内の情報を元に、レジスタ情報やコアファイル保存領域、その他の保存領域のメモリ５内のアドレスおよびサイズの内容からエラーの発生種類（ページフォルト、０割り算等）や、発生箇所（ＯＳ内／ＡＰ内）、エラー発生時のレジスタ情報等を収集する。

次に障害管理手段４４は、収集した障害情報を元にエラー原因の特定および、それに伴いプロセッサコア１の動作を継続させるか、それとも、そのエラーが継続できない障害でプロセッサコア１をシステムダウン（停止または再起動）にすべきかを判断する（図１７のＳ３１１）。システムダウンするケースとしては、障害発生の箇所がＡＰ２２が呼び出したＯＳ２１内で発生したエラーでＯＳ復帰ができないものや、ＣＰＵ内部エラーが発生した場合などが挙げられる。

そして障害管理手段４４は、障害情報の記録および出力を行う（図１６、図１７のＳ３１２）。障害管理手段４４は特定されたエラー原因や継続動作またはシステムダウン動作遷移情報、および収集した障害情報を、コンソール６に表示し、使用者に障害が発生したことを通知するとともに、バックアップメモリ８内のエラー情報格納域４２に、これら情報を記録し、障害発生後も使用者が障害発生情報を参照できるようにする。
次に障害管理手段４４は、プロセッサコア１の対処としてシステムダウンすべきか否か判断する（図１７のＳ３１３）。システムダウンすべき場合（Ｓ３１３のＹ）は、プロセッサコア１を停止状態にさせた後、メモリ５内のＯＳ２１用領域２７の内容をディスクに書き込む（メモリダンプ）などした後、プロセッサコア１のリブート（Ｈ／Ｗリセット）を行う（図１７のＳ３１４）。これにより、プロセッサコア１は初期状態に戻り、再度ＯＳ２１がブートされる。

Ｓ３１３にてシステムダウンしない場合（Ｓ３１３のＮ）、障害管理手段４４は、次に特定されたエラー原因を元に、各エラーに対応した処理をおこなう（図１７のＳ３１５）。これは、例えば０割り算によるエラーであれば、次にＡＰ２２が実行される場合は、０割り算のシグナルハンドラ（エラー発生に伴い呼び出される関数）を呼び出すようにＡＰ情報領域２９内のＡＰ２２のスタックを操作したり、セグメンテーションフォルトによるエラーであれば、コアファイル４１を作成する準備を行う。そして、障害管理手段４４は、コアファイル４１を作成するようなエラーである場合に、コアファイル作成処理を行う（図１６、図１７のＳ３１６）。この時、障害管理手段４４は、収集領域情報７２にあるＨＤＤ７に書き込むべき領域をＡＰ２２情報領域２９の内容と判断し、ＨＤＤ７内のコアファイル４１に書き込む。コアファイル４１の作成が終了すると、障害管理手段４４は、ＡＰ２２を再開させるために停止処理解除要求をプロセッサコア１に通知する（図１６、図１７のＳ３１７）。これは、プロセッサ間通信機能（図１の１６）を利用して、プロセッサコア１に割込みを通知することで行われる。この時、ＡＰ２２を継続動作させるか、削除すべきかの情報が付加される。

Ｓ３０７にてプロセッサコア１上でＡＰ２２が動作している間に、プロセッサコア２での障害情報の収集および記録が終了し、Ｓ３１７にてプロセッサコア２からプロセッサコア１に対しＡＰ２１の停止処理解除要求が実施されると、プロセッサコア１のプロセッサ間通信機能（図１の１５）がその割込みを受信し、ＯＳ２１内のプロセス切替手段３６を起動する（図１７のＳ３１８）。プロセス切替手段３６は、通知にて付加されたＡＰ２２を継続動作させるか、削除すべきかの情報を元に、ＡＰ２２の再開または終了を処理する（図１６、図１７のＳ３１９）。継続動作させる場合は、ＡＰ２２が動作していたプロセスをスケジューリング対象に戻し、終了させる場合は、ＡＰ２２が動作していたプロセスを削除する処理を行う。以上がこの実施の形態における情報処理装置の障害発生時の動作である。

この実施の形態３による情報処理装置の障害処理システムでは、収集すべき障害情報の領域をＯＳ内部情報とは別に設け、そこにレジスタ情報やコアファイル情報の領域アドレスとサイズおよび、情報のタイプを設定するようにしたので、障害情報を収集するプロセッサコアは、障害が発生したプロセッサコアで動作するＯＳに依存せずに障害情報の収集を行うことが可能となり、障害が発生したプロセッサコア上で次に動作すべきＡＰを迅速に動作させることができる、情報処理装置の障害処理システムを得ることができる。

また、この実施の形態では、ＯＳに依存することなく、障害情報の収集が可能となっているので、複数のプロセッサコアで、それぞれ異なるＯＳが動作していた場合においても、各ＯＳで発生した障害を、１つの障害情報収集プロセッサコア上で処理することができる、情報処理装置の障害処理システムを得ることができる。
なお、この実施の形態では、収集領域情報に格納される領域情報の内容を４つにしていたが、４つ以上でも、同様な情報処理装置の障害処理システムを得ることができる。

さらに、この実施の形態では、収集領域情報７２の設定を障害発生時に行うようにしているが、これをＯＳ初期化時や、プロセス切替時に実施しても同様な情報処理装置の障害処理システムを得ることができる。
またさらに、この実施の形態では、メモリダンプを行う際、ＯＳ２１用領域２７をプロセッサコア２が把握してダンプするようにしているが、メモリダンプの領域を収集領域情報に追加し、プロセッサコア２上で、その情報を元にメモリダンプすることや、複数のメモリダンプ領域を収集領域情報に追加し、分割したメモリ領域をダンプすることができるようにしても、同様な情報処理装置の障害処理システムを得ることができる。

実施の形態４．
この発明の他の実施形態における情報処理装置の障害処理システムについて説明する。実施の形態４では、情報処理装置のＨ／Ｗ構成は実施の形態１と同じであり、図１で示される。図１８は、図１で示したＨ／Ｗ構成に対する、ソフトウェア（Ｓ／Ｗ）の構成を示す図である。実施の形態４では、ＯＳ２１内に、メモリ５上のＯＳ２１用領域２７の各領域の読み書きをＡＰ毎に制御し、書込みの権利がないＡＰが書き込みを行った場合にトラップを発生させるようにＨ／Ｗに設定することを行う読み書き管理手段８０が存在し、同様にＯＳ２４内にも同様な読み書き管理手段８１が存在する。また、メモリ５上に、ＯＳ２１用領域内にＯＳ２１内の各ＡＰで領域を共有する共有メモリ領域８２と、ＯＳ２４用領域にＯＳ２４内の各ＡＰで領域を共有する共有メモリ領域８３が存在し、障害検出手段３５および３９、障害処理手段３４（３４’）および３８に、これら読み書き管理手段８０および８１および共有メモリ領域８２および８３に対する操作が追加される。それ以外は実施の形態１と同じである。この実施の形態４では、ＯＳ初期化時の動作は、実施の形態１と同じであり、図３の矢印および図４のフローチャートで示される。

次に、この実施の形態における情報処理装置の障害発生時の動作について、図１９内の矢印および図２０のフローチャートを用いて説明する。この実施の形態では、プロセッサコア１上で動作するＡＰ２２に障害が発生した場合の例で説明する。まず、ＡＰ２２の動作中に障害が発生すると、プロセッサコア１上で例外が発生し、ＯＳ２１内の障害検出手段３５が、その例外を検出する（図１９、図２０のＳ４１１）。そして障害検出手段３５は、最低限のレジスタ情報をメモリ５内に保存した後、読み書き管理手段８０を呼び出し、障害が発生したＡＰ２２が共有メモリ領域８２を使用していたか否かをチェックさせる(図１９、図２０のＳ４１２）。

読み書き管理手段８０では、ＡＰ２２が共有メモリ領域８２を使用している場合（図２０の４１２のＹ）、共有メモリ領域８２を書込み禁止に設定する（図１９、図２０のＳ４１３）。これにより、他ＡＰから共有メモリに書込みが発生すると、トラップが発生する。書込み禁止の設定方法としては、プロセッサコア１のＭＭＵ１８に対し、共有メモリ領域８２のアドレス空間に対し書き込みを禁止するような設定を行うことで、以降の書込みに対しトラップが発生させることができる。これには、ＭＭＵが使用するページテーブルにある、書込み禁止フラグや、ページ存在フラグなどを利用することが考えられる。読み書き管理手段８０にて共有メモリ領域８２を書込み禁止に設定（Ｓ４１３）した後、または、障害発生ＡＰが共有メモリを利用していなかった（Ｓ４１２のＮ）場合、読み書き管理手段８０の動作は終了し、障害検出手段３５に処理が戻り、障害が発生したＡＰ２２を停止させるためにプロセス切替手段３６に通知する（図１９、図２０のＳ４１４）。

障害検出手段３５により通知されたプロセス切替手段３６は、障害が発生したＡＰ２２の実行を停止する（図１９、図２０のＳ４１５）。これは、ＡＰ２２が動作していたプロセスをスケジューリング対象から外し、同プロセスの状態を停止状態に移行することを意味し、プロセスそのものを削除することはこの時点ではしない。プロセスそのものを削除しないことにより、ＡＰ２２が使用していたメモリ５内のＡＰ情報領域２９、および共有メモリ領域８２がそのまま残存し、これをプロセッサコア２上から参照することが可能となる。

また、共有メモリ領域８２については、他のＡＰから書込みがあるとトラップにより、書込みを防ぐようになっており、共有メモリ領域８２についてもＡＰ２２が障害にて停止した状態が維持される。次に障害検出手段３５は、プロセッサ間通信機能（図１の１５）を利用して、障害発生を障害処理するプロセッサコア２に通知する（図１９、図２０のＳ４１６）。この時、障害が発生したＡＰ２２の情報や保存したレジスタ情報などが付加される。そして障害処理手段３５は、プロセス切替手段３６を介して、他ＡＰへの切替を行う。プロセス切替手段３６は、ＯＳ２１内のプロセス情報を参照し、動作可能なＡＰ２３を抽出し、ＡＰ２３を動作可能（ＲＵＮ状態）にする（図１９、図２０のＳ４１７）。これにより以降、プロセッサコア１上ではＡＰ２３が動作する（図２０のＳ４１８）。

プロセッサコア２では、障害管理手段４４が動作しており、他プロセッサからの通知があるかチェックしている（図２０のＳ４１９）。Ｓ４１６にて、プロセッサコア１からプロセッサコア２に割込みが通知されると、プロセッサコア２のプロセッサ間通信機能（図１の１６）が、その割込みを検出し、障害管理手段４４に通知する（図１９、図２０のＳ４１９）。障害管理手段４４では、Ｓ４１９にてその通知をチェックしており、通知があれば（Ｓ４１９のＹ）、通知元プロセッサコアに対応する障害処理手段を登録領域４５内から見つけ出し、その手段を起動する（図１９、図２０のＳ４２０）。この実施の形態では、プロセッサコア１から通知されたので、登録領域４５内の障害処理手段３４’が起動される。この障害処理手段３４’は、プロセッサコア１内のＯＳ２１用のものであり、ＯＳ２１にあわせた障害処理が可能となる。

障害処理手段３４’は、まず、通知にて付加されたＡＰ２２の情報を元に、メモリ５のＯＳ２１用領域２７内のＡＰ情報領域２９を探し、その中にある情報からエラーの発生種類（ページフォルト、０割り算等）や、発生箇所（ＯＳ内／ＡＰ内）、エラー発生時のレジスタ情報等を収集する（図１９、図２０のＳ４２１）。
次に障害処理手段３４’は、収集されたＡＰ２２の障害情報を元にエラー原因の特定および、それに伴いプロセッサコア１の動作を継続させるか、それとも、そのエラーが継続できない障害でプロセッサコア１をシステムダウン（停止または再起動）にすべきかを判断する（図２０のＳ４２２）。そして障害処理手段３４’は、特定されたエラー原因や継続動作またはシステムダウン動作遷移情報、および収集された障害情報を、コンソール６に表示し、使用者に障害が発生したことを通知するとともに、バックアップメモリ８内のエラー情報格納域４２に、これら情報を記録し、障害発生後も使用者が障害発生情報を参照できるようにする（図１９、図２０のＳ４２３）。

次に障害処理手段３４’は、プロセッサコア１の対処としてシステムダウンすべきか否か判断する（図２０のＳ４２４）。システムダウンすべき場合（Ｓ４２４のＹ）は、プロセッサコア１を停止状態にさせた後、メモリ５内のＯＳ２１用領域２７の内容をディスクに書き込む（メモリダンプ）などした後、プロセッサコア１のリブート（Ｈ／Ｗリセット）を行う（図２０のＳ４２５）。これにより、プロセッサコア１は初期状態に戻り、再度ＯＳ２１がブートされる。

Ｓ４２２にてシステムダウンしない場合（Ｓ４２４のＮ）、障害処理手段３４’は、特定されたエラー原因を元に、各エラーに対応した処理をおこなう（図２０のＳ４２６）。これは、例えば０割り算によるエラーであれば、次にＡＰ２２が実行される場合は、０割り算のシグナルハンドラ（エラー発生に伴い呼び出される関数）を呼び出すようにＡＰ情報領域２９内のＡＰ２２のスタックを操作したり、セグメンテーションフォルトによるエラーであれば、コアファイル４１を作成する準備を行う。

そして、障害処理手段３４’は、コアファイル４１を作成するようなエラーである場合に、コアファイル作成処理を行う（図１９、図２０のＳ４２７）。この時、障害処理手段３４’は、ＡＰ情報領域２９の内容およびＡＰ２２が共有メモリを使用していれば共有メモリ領域８２の内容をＨＤＤ７内のコアファイル４１に書き出す。コアファイル４１の作成が終了すると、障害処理手段３４’は、ＡＰ２２を再開させるために停止処理解除要求をプロセッサコア１に通知する（図１９、図２０のＳ４２８）。これは、プロセッサ間通信機能（図１の１６）を利用して、プロセッサコア１に割込みを通知することで行われる。この時、ＡＰ２２を継続動作させるか、削除すべきかの情報が付加される。

Ｓ４１８にてプロセッサコア１上でＡＰ２３が動作している間に、プロセッサコア２での障害情報の収集および記録が終了し、Ｓ４２８にてプロセッサコア２からプロセッサコア１に対しＡＰ２２の停止処理解除要求が実施されると、プロセッサコア１のプロセッサ間通信機能（図１の１５）がその割込みを受信し、ＯＳ２１内のプロセス切替手段３６を起動する（図２０のＳ４２９）。プロセス切替手段３６はまず、読み書き管理手段８０を呼び出し、障害が発生していたＡＰ２２が共有メモリ領域８２を使用していたかチェックさせる（図１９、図２０のＳ４３０）。

読み書き管理手段８０では、ＡＰ２２が共有メモリ領域を８２を使用していた場合（図２０のＳ４３０のＹ）、既に障害が発生したＡＰ２２に対する障害処理は終了しており、かつ、共有メモリ領域８２には、Ｓ４１３にて書込み禁止に設定されていたため、共有メモリ領域８２の書込み禁止を解除する（図１９、図２０のＳ４３１）。これにより、以降、他ＡＰが共有メモリ８２に書込み操作を行っても、トラップは発生せず、直接書き込むことが可能となる。

読み書き管理手段８０にて共有メモリ領域を書込み禁止解除に設定（Ｓ４３１）した後、または、障害発生ＡＰが共有メモリを使用していなかった（Ｓ４３０のＮ）場合、読み書き管理手段８０の動作は終了し、プロセス切替手段３６に処理が戻り、プロセス切替手段３６は、プロセッサコア２からの通知にて付加されたＡＰ２２を継続動作させるか、削除すべきかの情報を元に、ＡＰ２２の再開または終了を処理する（図１９、図２０のＳ４３２）。継続動作させる場合は、ＡＰ２２が動作していたプロセスをスケジューリング対象に戻し、終了させる場合は、ＡＰ２２が動作していたプロセスを削除する処理を行う。以上がこの実施の形態における情報処理装置の障害発生時の動作である。

次に、この実施の形態における情報処理装置の共有メモリ領域８２に書込み禁止設定になっていた場合の、他ＡＰによる書込み操作が実施された時の動作について、図２１の矢印および図２２のフローチャートを用いて説明する。この実施の形態では、ＡＰ２２およびＡＰ２３が共有メモリ領域８２を使用しており、ＡＰ２２に障害が発生し、ＡＰ２２の障害処理操作の過程で共有メモリ領域８２が書込み禁止設定（図１９、図２０のＳ４１３）になっている時に、ＡＰ２３が共有メモリ領域８２に書込みを行おうとした場合の例で説明する。まず、ＡＰ２３（他ＡＰ）が共有メモリ領域８２に書込み操作を行う（図２１、図２２のＳ４５１）。すると、それをプロセッサコア１が検知し、トラップを発生し、そのトラップを読み書き管理手段８０が検出する（図２１、図２２のＳ４５２）。

読み書き管理手段８０は、トラップ処理内にてＡＰ２３が共有メモリ領域８２内のどこに書き込もうとしていたかを判断すると共に、ＯＳ２１用領域２７にある空きメモリ領域８４から、空きメモリを確保する（図２１、図２２のＳ４５３）。確保する量は、プロセッサコア１のＭＭＵ１８によって管理される、アドレス空間の最小単位（ページテーブルにて管理できる最小サイズ。インテル社ｘ８６系プロセッサでは１ページ＝４ＫＢ）の量となる。

次に読み書き管理手段８０は、ＡＰ２３が共有メモリ領域８２内の書き込もうとしていた領域の内容をＳ４５３にて確保した領域にコピーする（図２１、図２２のＳ４５４）。このコピーする量も、空きメモリを確保した量と同じであり、書き込もうとした領域が含まれる、アドレス空間の最小単位の領域全てが、確保した空きメモリ領域にコピーされる（例えば、アドレス空間の最小単位４ＫＢにて、アドレス０ｘ８０００００１０から始まる４バイトの領域に書き込もうとしていた場合、０ｘ８０００００００〜０ｘ８００００ｆｆｆの領域がコピーされる）。

次に、読み書き管理手段８０は、ＡＰ２３が共有メモリ領域８２に対して行おうとしていた書込み操作を、コピーした領域に対して行わせるように、ＡＰ２３の領域設定を切り替える（図２１、図２２のＳ４５５）。これは、ＡＰ２３のアドレス空間にて、共有メモリ領域８２として参照していた空間を、Ｓ４５４にてコピーした領域を参照するように切り替える。具体的には、プロセッサコア１のＭＭＵ１８が参照しているページテーブルにある、ＡＰ２３が書き込もうとしていた領域に対するアドレスに対するテーブルを、Ｓ４５４にてコピーした領域に対するアドレスに切り替えることで、Ｓ４５４にてコピーした領域がＡＰ２３が書き込もうとしていたアドレス空間に対し参照可能となる。これにより、以降ＡＰ２３が共有メモリ８２の同様な領域を書き込もうとしても、アドレス空間としては、コピーした領域を参照しているので、コピーした領域に対し、書込みが発生し、障害が発生したＡＰ２２が参照している共有メモリ領域に書込みは発生しない。

次に読み書き管理手段８０は、ＡＰ２３が共有メモリ８２内の書き込もうとしていた領域が、他ＡＰにて参照しているかチェックする（図２２のＳ４５６）。他ＡＰにて参照している場合（Ｓ４５６のＹ）、他ＡＰにて参照している共有メモリ８２内の該当領域を、Ｓ４５４にてコピーした領域になるよう、他ＡＰのアドレス空間の設定を変更する。これにより、以降、ＡＰ２２、ＡＰ２３以外のＡＰも、ＡＰ２３によって書込みが発生した領域を共有メモリ領域として参照することが可能となり、障害が発生しているＡＰ２２が参照していた共有メモリは障害発生時の状態を保ったまま、他ＡＰについては、共有メモリの操作が可能で、かつ、最新の共有メモリ状態を参照することが可能となる。

Ｓ４５７にて他のＡＰに対する共有メモリ設定の変更を行った後、または、ＡＰ２３が書き込もうとした領域を他のＡＰが使用していなかった（Ｓ４５６のＮ）場合、読み書き手段８０の動作は終了し、トラップ処理を復帰し（図２２のＳ４５８）、ＡＰ２３の共有メモリ領域８２に対する書込み操作が継続される。この時、既に、書き込もうとした領域はＳ４５４にてコピーした領域であり、ＡＰ２２が参照していた共有メモリ領域８２は、障害発生時のデータがそのまま残っている。以上が、この実施の形態における、共有メモリ領域８２が書き込み禁止設定になっていた場合の、他ＡＰによる書込み操作が実施された時の動作である。

この実施の形態４による情報処理装置の障害処理システムでは、各ＡＰで同じメモリを読み書きすることができる共有メモリ領域に対し、共有メモリの書込みを禁止し、書込みが発生した場合はトラップが発生するような設定と、トラップが発生した場合の処理を行う読み書き管理手段を設け、ＡＰに障害が発生し、そのＡＰが共有メモリを参照している場合は読み書き管理手段にて、他ＡＰに対し、共有メモリを書込み禁止にするような設定を行い、障害が発生していないＡＰが、その共有メモリ領域に書込みを行うことでトラップが発生すると、読み書き管理手段にて、書き込もうとしていた領域に対し代替となる領域を確保するとともに、書き込もうとしていていた領域の内容を代替領域にコピーし、書き込もうとしていたＡＰを含む、障害発生ＡＰ以外のＡＰの共有メモリ領域を、その代替領域を参照するように、各ＡＰのアドレス空間を切り替えるようにしたので、障害発生ＡＰの障害処理は障害発生時の状態を保存でき、かつ、他ＡＰの共有メモリ操作も継続して実行できるようにすることで、障害が発生したプロセッサ上で次に動作すべきＡＰを迅速に動作させることができる情報処理装置の障害処理システムを得ることができる。

なお、この実施の形態では、代替領域への切替を、書き込もうとしたＡＰのアドレス空間に対して行ったが、これを障害発生ＡＰに対して切り替えるようにしても同様な情報処理装置の障害処理システムを得ることができる。この場合、書き込もうとした領域の内容を確保した空きメモリ領域にコピーした後、障害発生ＡＰのアドレス空間の共有メモリ領域を、確保した領域に切り替えるとともに、書き込もうとしたＡＰを含む傷害発生ＡＰ以外のＡＰのアドレス空間に対し、書込み禁止の設定を解除する。これにより、障害発生ＡＰ以外のＡＰの書込みは共有メモリ領域に対して行われるが、障害発生ＡＰの共有メモリ領域に対するアドレス空間は、確保した領域を参照するため、障害発生ＡＰの障害処理は、障害発生時の状態で共有メモリ領域を参照することができる。

また、この実施の形態では、Ｓ４５６、Ｓ４５７にて、書込み操作を実施しようとしたＡＰ以外のＡＰに対する共有メモリ領域８２に対する処理を行っているが、ここで処理を行わず、次に他ＡＰが同領域に書込みを行った際に、既に代替領域があるか否かをチェックし、代替領域がなければ代替領域の確保およびコピーを、あれば、代替領域を参照するように自身のアドレス空間を切り替える設定をするようにしても、同様な情報処理装置の障害処理システムを得ることができる。

実施の形態５．
この発明の他の実施の形態における情報処理装置の障害処理システムについて説明する。実施の形態５では、情報処理装置のＨ／Ｗ構成は実施の形態１と同じであり、図１で示される。図２３は、図１で示したＨ／Ｗ構成に対する。ソフトウェア（Ｓ／Ｗ）の構成を示す図である。図中、プロセッサコア１には、ＯＳ２１と、ＯＳ２１で動作するＡＰ２２、ＡＰ２３が動作する。同様にプロセッサコア２には、ＯＳ１２１と、ＯＳ１２１上で動作するＡＰ１２２、およびＡＰ１２３が、プロセッサコア３にはＯＳ２４と、ＯＳ２４上で動作するＡＰ２５とＡＰ２６が存在する。また、ＯＳ２１、ＡＰ２２、ＡＰ２３、およびＯＳ１２１、ＡＰ１２２、ＡＰ１２３、およびＯＳ２４、ＡＰ２５、ＡＰ２６、のコード／データ、およびヒープ／スタック領域はメモリ５上に存在する。

メモリ５上には、ＯＳ２１が使用するＯＳ２１用領域２７と、ＯＳ２４が使用するＯＳ２４用領域２８と、ＯＳ１２１が使用するＯＳ１２１用領域１３２とに用途が区切られており、ＯＳ２１用領域２７内には、ＯＳ２１上で動作するＡＰ２２のコード／データおよびヒープスタック領域であるＡＰ情報領域２９と、ＯＳ２１上で動作するＡＰ２３のコード／データおよびヒープ／スタック領域であるＡＰ情報領域３０が、ＯＳ２４用領域２８には、ＯＳ２４上で動作するＡＰ２５のコード／データおよびヒープ／スタック領域であるＡＰ情報領域３１と、ＯＳ２４上で動作するＡＰ２６のコード／データおよびヒープスタック領域であるＡＰ情報領域３２が、ＯＳ１２１用領域１３２内には、ＯＳ１２１上で動作するＡＰ１２２のコード／データおよびヒープ／スタック領域であるＡＰ情報領域１３３と、ＯＳ１２１上で動作するＡＰ１２３のコード／データおよびヒープ／スタック領域であるＡＰ情報領域１３４が存在する。

また、メモリ５上には、各プロセッサコアが処理すべきものが何もない（アイドル状態）時に、アイドル状態を他のプロセッサコアに知らしめるための、待ちキュー１３５が存在する。この実施の形態では、プロセッサコア２およびプロセッサコア３がアイドル状態であり、待ちキュー１３５には、プロセッサコア２がアイドル状態であることを示す待ち１３６と、プロセッサコア３がアイドル状態であることを示す待ち１３７がリンクされている。

プロセッサコア１、プロセッサコア２、およびプロセッサコア３にある、ＯＳ２１、ＯＳ１２１、ＯＳ２４には、それぞれプロセッサコア上で動作するＡＰに障害が発生した場合に、障害を検知し、対処する手段と、他のプロセッサコアの指示により障害情報を収集・記録する手段が存在する。プロセッサコア１上のＯＳ２１には、ＯＳの初期化処理を行うＯＳ初期化手段３３と、障害発生時にＯＳ２１に対応した障害処理を他プロセッサコア上で行うための障害処理手段３４、ＡＰの障害を検出する障害検出手段３５と、ＡＰの動作を切り替えるためのプロセス切替手段３６が存在し、他プロセッサコアで動作するＯＳに対応する障害処理手段の登録処理および他プロセッサコアからの指示により障害処理手段を起動する障害管理手段１０１が存在する。さらに、他プロセッサコア上のＯＳに対応する障害処理手段を格納するための登録領域１０２が存在し、かつ、プロセッサコア上で処理すべきものが何もない（アイドル状態）ことを検出するアイドル状態検出手段１０３と、プロセッサコア上で処理すべきものが存在する（非アイドル状態）ことを検出する非アイドル状態検出手段１０４が存在する。

同様な手段は、プロセッサコア２上のＯＳ１２１、およびプロセッサコア３上のＯＳ２４にも存在する。プロセッサコア２上のＯＳ１２１には、ＯＳ初期化手段１２４、障害処理手段１２５、障害検出手段１２６、プロセス切替手段１２７、障害管理手段１２８、登録領域１２９、アイドル状態検出手段１３０、非アイドル状態検出手段１３１が存在し、プロセッサコア３上のＯＳ２４には、ＯＳ初期化手段３７、障害処理手段３８、障害検出手段３９、プロセス切替手段４０、障害管理手段１１１、登録領域１１２、アイドル状態検出手段１１３、非アイドル状態検出手段１１４が存在する。

次に、この実施の形態における情報処理装置のＯＳ初期化時の動作について、図２４の矢印および図２５のフローチャートを用いて説明する。まず、プロセッサコア１にＨ／Ｗリセットが掛かり、ＯＳ２１が起動されると、ＯＳ初期化手段３３が動作する。プロセッサコア１のＯＳ初期化手段３３は、ＯＳ内の様々な機能の初期化を行うと共に、プロセッサコア１を含め、全プロセッサコアに対し、ＯＳ２１内にある障害処理手段３４の登録を依頼する(図２４および図２５のＳ５０１）。この登録依頼処理は、プロセッサコア１、プロセッサコア２、プロセッサコア３内のプロセッサ間通信機能（図１の１５、１６、１７）を用いて行われる。プロセッサコア２は、ＯＳ１２１の起動後、ＯＳ２１と同様にＯＳ初期化処理手段３３が動作した後、障害管理手段１２８が動作し、他プロセッサコアからの通知を待つ（図２５のＳ５０２）。

他プロセッサコアからの通知がない場合は、再度通知を待つ（Ｓ５０２のＮ）。他プロセッサコアから通知があった場合（Ｓ５０２のＹ）、依頼されたプロセッサコア１から障害処理手段３４の内容を受信し、登録領域４５内に障害処理手段３４”として格納する（図２４および図２５のＳ５０３）。そして再度、他プロセッサからの通知を待つ(Ｓ５０２）。このようにして、プロセッサコア２内の登録領域４５には、プロセッサコア１上で動作する各ＯＳに対応した障害処理手段が格納されることになる。

同様にプロセッサコア３でもプロセッサコア１からの通知により、登録領域１１２に障害処理手段３４の内容が格納される。さらに、プロセッサコア１自身もＯＳ初期化処理手段３３からの通知により、自身の登録領域１０２に自身の障害処理手段３４の内容が障害処理手段３４’として格納される。また、プロセッサコア２上のＯＳ初期化処理手段１２４、およびプロセッサコア３上のＯＳ初期化処理手段３７も、プロセッサコア１のＯＳ初期化処理手段３３と同じ動作を行う。

プロセッサコア２上のＯＳ１２１のＯＳ初期化手段１２４は、プロセッサコア２を含む、全プロセッサコアに対し、ＯＳ１２１内にある障害処理手段１２５の登録を依頼し、プロセッサコア３上のＯＳ２４のＯＳ初期化手段３７は、プロセッサコア３を含む、全プロセッサコアに対し、ＯＳ２４内にある障害処理手段３８の登録を依頼する。それぞれの依頼に対し、各プロセッサコア障害管理手段がそれぞれの登録領域に、障害処理手段の内容を格納する。

これにより、プロセッサコア１の登録領域１０２には、プロセッサコア１用の障害処理手段３４’とプロセッサコア２用の障害処理手段１２５’とプロセッサコア３用の障害処理手段３８’が存在し、プロセッサコア２の登録領域１２９には、プロセッサコア１用の障害処理手段３４”とプロセッサコア２用の障害処理手段１２５”とプロセッサコア３用の障害処理手段３８”が存在し、プロセッサコア３の登録領域１１２にも各プロセッサコア用の障害処理手段が存在するようになる。

この実施の形態では、プロセッサコア２の障害処理登録手段４３が、他プロセッサコアからの通知を待っているように記載しているが、これを割込みベースにしても動作は同じである。この場合、プロセッサコア２にて他の処理を行っている最中に、プロセッサ間通信機能（図１の１６）にて割込みが発生し、その割込み処理にて障害処理登録手段４３が起動し、登録処理が実施された後、プロセッサコア２は、割込みが発生した時に行っていた処理に戻る。以上がこの実施の形態における情報処理装置のＯＳ初期化時の動作である。

次に、この実施の形態における情報処理装置の定常状態の動作について、図２６内の矢印および図２７のフローチャートを用いて説明する。この実施の形態では、プロセッサコア２上での動作を例に説明するが、プロセッサコア１およびプロセッサコア３でも同様な動作になる。まず、プロセッサコア２上でＡＰが動作している（図２７のＳ５１１）状態で、ＡＰの動作が終了（または、Ｉ／Ｏ要求等の待ちになる）すると（図２７のＳ５１２）、制御がＯＳ１２１のプロセス切替手段１２７に移り、プロセス切替手段１２７は、次に動作可能なＡＰが存在するかチェックする（図２７のＳ５１３）。

動作可能なＡＰが存在しない場合、アイドル状態になるため、プロセス切替手段１２７はアイドル状態検出手段１３０を呼び出す（図２６、図２７のＳ５１３のＮ）。アイドル状態検出手段１３０は、メモリ５上の待ちキュー１３５に自プロセッサコア（プロセッサコア２）が既に登録済になっているかチェックを行う（図２７のＳ５１４）。待ちキュー１３５に自プロセッサコアが登録されていない場合（Ｓ５１４のＮ）、アイドル状態検出手段１３０は、プロセッサコア２が他の処理をすることが可能なことを他のプロセッサコアに知らせるために、待ちキュー１３５に、待ち１３６を繋げる(図２６、図２７のＳ５１５）。

待ちキュー１３５には、それがプロセッサコア２であることを意味するための情報（プロセッサコア番号やＯＳ番号等）を格納しておく。これにより、他プロセッサコアからこのプロセッサコアに対し、障害対応処理を要求することを受け付けられるようになる。そして、アイドル検出手段１３０の処理は終了し、プロセス切替手段１２７はアイドル状態に遷移する（図２７のＳ５１６）。その後、再度Ｓ５１３に戻り、動作可能なＡＰが存在するかチェックする。Ｓ５１４にて待ちキュー１３５に自プロセッサコアが既に登録されている場合（Ｓ５１４Ｙ）は、アイドル状態検出手段１３０は処理を終了し、プロセス切替手段１２７はアイドル状態に遷移する（図２７のＳ５１６）。

Ｓ５１３にて、動作可能なＡＰが存在する場合、ＡＰを動作させることにより、非アイドル状態になるため、プロセス切替手段１２７は非アイドル状態検出手段１３１を呼び出す（図２６、図２７のＳ５１３のＹ）。非アイドル状態検出手段１３１は、メモリ５上の待ちキュー１３５に自プロセッサコア（プロセッサコア２）が既に登録済みになっているかチェックを行う（図２７のＳ５１７）。待ちキュー１３５に自プロセッサコアが登録されている場合（図２７のＳ５１７のＹ）、自プロセッサコアがアイドル状態から外れたので、待ちキュー１３５から、待ち１３６を削除する（図２６、図２７のＳ５１８）。これにより、他プロセッサコアからこのプロセッサコアに対し、障害対応処理を要求されることはなくなる。そして、非アイドル状態検出手段１３１の処理は終了し、該当するＡＰの動作が開始される（図２７のＳ５１１）。Ｓ５１７にて待ちキュー１３５に自プロセッサコアが登録されていない場合は、直ぐに非アイドル状態検出手段１３１の処理を終了し、該当するＡＰの動作が開始される（図２７のＳ５１１）。

以上が、この実施の形態に置ける情報処理装置の定常状態の動作である。なお、この実施の形態では、アイドル状態および非アイドル状態の検出をプロセス切替手段１２７からの呼び出しを契機として説明しているが、アイドル状態の検出については、アイドル検出手段１３０を、ＡＰの動作と同様に１つの実行単位（プロセス）とし、一番低い優先度で動作させることにより、ＯＳ１２１上で動作するするＡＰが何もなくなったとき、アイドル検出手段１３０プロセスが動作し、待ちキュー１３５に対するプロセッサコア２の登録を行うことでも同様な機能を実現可能である。さらに、非アイドル状態の検出については、外部からの割込みを受信する割込みハンドラから非アイドル状態検出手段１３１を実行させることでも、同様な機能を実現可能である。

次に、この実施の形態における情報処理装置の障害発生時の動作について、図２８内の矢印および図２９のフローチャートを用いて説明する。この実施の形態では、プロセッサコア２およびプロセッサコア３がアイドル状態の時に、プロセッサコア１上で動作するＡＰ２２に障害が発生した場合の例で説明する。

まず、ＡＰ２２の動作中に障害が発生すると、プロセッサコア１上で例外が発生し、ＯＳ２１内の障害検出手段３５が、その例外を検出する（図２８、図２９のＳ５２０）。そして障害検出手段３５は、最低限のレジスタ情報をメモリ５内に保存した後、障害が発生したＡＰ２２を停止させるためにプロセス切替手段３６に通知する（図２８、図２９のＳ５２１）。障害検出手段３５により通知されたプロセス切替手段３６は、障害が発生したＡＰ２２の実行を停止する（図２８、図２９のＳ５２２）。これは、ＡＰ２２が動作していたプロセスをスケジューリング対象から外し、同プロセスの状態を停止状態に移行することを意味し、プロセスそのものを削除することはこの時点ではしない。プロセスそのものを削除しないことにより、ＡＰ２２が使用していたメモリ５内のＡＰ情報領域２９がそのまま残存し、これを他のプロセッサコアから参照することが可能となる。

次に障害検出手段３５は、待ちキュー１３５に繋がれているプロセッサコアが存在するかチェックする（図２８、図２９のＳ５２３）。待ちキュー１３５に他プロセッサコアの待ちが繋がれている場合（Ｓ５２３のＹ）、障害処理を他プロセッサに依頼することができるので、障害検出手段３５は、待ちキュー１３５を参照し、そこに繋がれている待ち、この実施の形態ではプロセッサコア２の待ち１３６の情報から、障害の処理が対応可能なプロセッサコア２を見つけ出すとともに、待ち１３６を待ちキュー１３５から削除する（図２７のＳ５２４）。

次に障害検出手段３５は、プロセッサ間通信機能（図１の１５）を利用して、障害発生を障害処理するプロセッサコア２に通知する（図２８、図２９のＳ５２５）。この時、障害が発生したＡＰ２２の情報や保存したレジスタ情報などが付加される。そして障害処理手段３５は、プロセス切替手段３６を介して、他ＡＰへの切替を行う。プロセス切替手段３６は、ＯＳ２１内のプロセス情報を参照し、動作可能なＡＰ２３を抽出し、ＡＰ２３を動作可能（ＲＵＮ状態）にする（図２８、図２９のＳ５２６）。これにより以降、プロセッサコア１上ではＡＰ２３が動作する（図２９のＳ５２７）。

プロセッサコア２では、待ちキュー１３５に自身の待ち１３６を繋げている状態であり、アイドル状態となっている。この時、障害管理手段１２８が動作しており、他プロセッサからの通知があるかチェックしている（図２９のＳ５２８）。Ｓ５２８にて、プロセッサコア１からプロセッサコア２に割込みが通知されると、プロセッサコア２のプロセッサ間通信機能（図１の１６）が、その割込みを検出し、障害管理手段１２８に通知する。障害管理手段１２８では、Ｓ５２８にてその通知をチェックしており、通知があれば（Ｓ５２８のＹ）、通知元プロセッサコアに対応する障害処理手段を登録領域１２９内から見つけ出し、その手段を起動する（図２８、図２９のＳ５２９）。

この実施の形態では、プロセッサコア１から通知されたので、登録領域１２９内の障害処理手段３４”が起動される。この障害処理手段３４”は、プロセッサコア１内のＯＳ２１用のものであり、ＯＳ２１にあわせた障害処理が可能となる。障害処理手段３４”は、まず、通知にて付加されたＡＰ２２の情報を元に、メモリ５のＯＳ２１用領域２７内のＡＰ情報領域２９を探し、その中にある情報からエラーの発生種類（ページフォルト、０割り算等）や、発生箇所（ＯＳ内／ＡＰ内）、エラー発生時のレジスタ情報等を収集する（図２８、図２９のＳ５３０）。

次に障害処理手段３４”は、収集されたＡＰ２２の障害情報を元にエラー原因の特定および、それに伴いプロセッサコア１の動作を継続動作させるか、それとも、そのエラーが継続できない障害でプロセッサコア１をシステムダウン（停止または再起動）にすべきかを判断する（図２９のＳ５３１）。システムダウンするケースとしては、障害発生の箇所がＡＰ２２が呼び出したＯＳ２１内で発生したエラーでＯＳ復帰ができないものや、ＣＰＵ内部エラーが発生した場合などが挙げられる。そして障害処理手段３４”は、特定されたエラー原因や継続動作またはシステムダウン動作遷移情報、および収集された障害情報を、コンソール６に表示し、使用者に障害が発生したことを通知するとともに、バックアップメモリ８内のエラー情報格納域４２に、これら情報を記録し、障害発生後も使用者が障害発生情報を参照できるようにする（図２８、図２９のＳ５３２）。

次に障害処理手段３４”は、プロセッサコア１の対処としてシステムダウンすべきか否か判断する（図２９のＳ５３３）。システムダウンすべき場合（Ｓ５３３のＹ）は、プロセッサコア１を停止状態にさせた後、メモリ５内のＯＳ２１用領域２７の内容をディスクに書き込む（メモリダンプ）などした後、プロセッサコア１のリブート（Ｈ／Ｗリセット）を行う（図２９のＳ５３４）。これにより、プロセッサコア１は初期状態に戻り、再度ＯＳ２１がブートされる。

Ｓ５３３にてシステムダウンしない場合（Ｓ５３３のＮ）、障害処理手段３４”は、特定されたエラー原因を元に、各エラーに対応した処理をおこなう（図２９のＳ５３５）。これは、例えば０割り算によるエラーであれば、次にＡＰ２２が実行される場合は、０割り算のシグナルハンドラ（エラー発生に伴い呼び出される関数）を呼び出すようにＡＰ情報領域２９内のＡＰ２２のスタックを操作したり、セグメンテーションフォルトによるエラーであれば、コアファイル４１を作成する準備を行う。そして、障害処理手段３４”は、コアファイル４１を作成するようなエラーである場合に、コアファイル作成処理を行う（図２８、図２９のＳ５３６）。 この時、障害処理手段３４”は、ＡＰ情報領域２９の内容をＨＤＤ７内のコアファイル４１に書き出す。

コアファイル４１の作成が終了すると、障害処理手段３４”は、ＡＰ２２を再開させるために停止処理解除要求をプロセッサコア１に通知する（図２８、図２９のＳ５３７）。これは、プロセッサ間通信機能（図１の１６）を利用して、プロセッサコア１に割込みを通知することで行われる。この時、ＡＰ２２を継続動作させるか、削除すべきかの情報が付加される。この後、障害処理手段３４”の処理は終了し、障害管理手段１２８に戻る。

障害管理手段１２８は、定常状態の処理に戻る（図２９、Ｓ５１８）。定常状態の処理（図２７）では、アイドル状態時（図２７のＳ５１６）から、障害管理手段１２８が呼び出されているので、再度動作可能なＡＰがいるかチェック(図２７のＳ５１３）し、動作可能なＡＰがいなければ（図２７のＳ５１３のＮ）、再度待ちキュー１３５に待ち１３６を繋げ（図２７のＳ５１５）、アイドル状態に遷移（図２７のＳ５１６）し、動作可能なＡＰがいれば（図２７のＳ５１３のＹ）、待ちキューに登録済みか否かのチェック（図２７のＳ５１７、図２９のＳ５２４にて待ちキューへの登録は削除されているので、Ｓ５１７のＮを実行）し、そのＡＰに制御を移す（図２７のＳ５１１）。

Ｓ５２７にてプロセッサコア１上でＡＰ２３が動作している間に、プロセッサコア２での障害情報の収集（図２９のＳ５３０）および記録（図２９のＳ５３６）が終了し、Ｓ５３７にてプロセッサコア２からプロセッサコア１に対しＡＰ２２の停止処理解除要求が実施されると、プロセッサコア１のプロセッサ間通信機能（図１の１５）がその割込みを受信し、ＯＳ２１内のプロセス切替手段３６を起動する（図２９のＳ５３９）。プロセス切替手段３６は、通知にて付加されたＡＰ２２を継続動作させるか、削除すべきかの情報を元に、ＡＰ２２の再開または終了を処理する（図２８、図２９のＳ５４０）。継続動作させる場合は、ＡＰ２２が動作していたプロセスをスケジューリング対象に戻し、終了させる場合は、ＡＰ２２が動作していたプロセスを削除する処理を行う。

Ｓ５２３にて待ちキュー１３５に他のプロセッサコアの待ちがつながれていない場合（Ｓ５２３のＮ）、他プロセッサでＡＰ２２の障害処理を実施することができないため、プロセッサコア１自身で障害処理が行うため、障害検出手段３５は、プロセッサコア１自身の障害管理手段１０１を呼び出す。障害管理手段１０１は、登録領域１０２からプロセッサコア１自身の障害処理手段３４’を見つけ出し、起動する（図２９のＳ５４１）。障害処理手段３４’は、まず、通知にて付加されたＡＰ２２の情報を元に、メモリ５のＯＳ２１用領域２７内のＡＰ情報領域２９を探し、その中にある情報からエラーの発生種類（ページフォルト、０割り算等）や、発生箇所（ＯＳ内／ＡＰ内）、エラー発生時のレジスタ情報等を収集する（図２９のＳ５４２）。

次に障害処理手段３４’は、収集されたＡＰ２２の障害情報を元にエラー原因の特定および、それに伴いプロセッサコア１の動作を継続動作させるか、それとも、そのエラーが継続できない障害でプロセッサコア１をシステムダウン（停止または再起動）にすべきかを判断する（図２９のＳ５４３）。そして障害処理手段３４’は、特定されたエラー原因や継続動作またはシステムダウン動作遷移情報、および収集された障害情報を、コンソール６に表示し、使用者に障害が発生したことを通知するとともに、バックアップメモリ８内のエラー情報格納域４２に、これら情報を記録し、障害発生後も使用者が障害発生情報を参照できるようにする（図２９のＳ５４４）。

次に障害処理手段３４’は、プロセッサコア１の対処としてシステムダウンすべきか否か判断する（図２９のＳ５４５）。システムダウンすべき場合（Ｓ５４５のＹ）は、メモリ５内のＯＳ２１用領域２７の内容をディスクに書き込む（メモリダンプ）などした後、リブート（Ｈ／Ｗリセット）を行う（図２９のＳ５４６）。これにより、プロセッサコア１は初期状態に戻り、再度ＯＳ２１がブートされる。
Ｓ５４５にてシステムダウンしない場合（Ｓ５４５のＮ）、障害処理手段３４’は、特定されたエラー原因を元に、各エラーに対応した処理をおこなう（図２９のＳ５４７）。これは、例えば０割り算によるエラーであれば、次にＡＰ２２が実行される場合は、０割り算のシグナルハンドラ（エラー発生に伴い呼び出される関数）を呼び出すようにＡＰ情報領域２９内のＡＰ２２のスタックを操作したり、セグメンテーションフォルトによるエラーであれば、コアファイル４１を作成する準備を行う。そして、障害処理手段３４’は、コアファイル４１を作成するようなエラーである場合に、コアファイル作成処理を行う（図２９のＳ５４８）。この時、障害処理手段３４’は、ＡＰ情報領域２９の内容をＨＤＤ７内のコアファイル４１に書き出す。

コアファイル４１の作成が終了すると、障害処理手段３４’は、ＡＰ２２の停止解除を行うためにプロセス切替手段３６を起動する（図２９のＳ５４９）。プロセス切替手段３６は、ＡＰ２２を継続動作させるか、削除すべきかの情報を元に、ＡＰ２２の再開または終了を処理する（図２９のＳ５４０）。継続動作させる場合は、ＡＰ２２が動作していたプロセスをスケジューリング対象に戻し、終了させる場合は、ＡＰ２２が動作していたプロセスを削除する処理を行う。以上がこの実施の形態における情報処理装置の障害発生時の動作である。

この実施の形態５による情報処理装置の障害処理システムでは、各プロセッサコアに障害処理用の手段を設け、メモリ上に待ちキューを備え、各プロセッサコアが、自身ですべき処理が何もないときに、待ちキューに自身の情報を登録し、何らかの処理が発生した場合に待ちキューから自身の情報を削除する。障害が発生したプロセッサは、待ちキューにつながれているプロセッサコアの情報を元に、障害処理が可能なプロセッサコアに障害が発生したことを通知し、通知されたプロセッサコアは、自身の持っている障害処理用の手段を用いて、障害発生プロセッサで動作していたＡＰの障害情報の収集／記録、および障害に対する対処を行うようにしたので、障害処理用のプロセッサコアを持たない場合でも、障害が発生したプロセッサ上で次に動作すべきＡＰを迅速に動作させることができる、情報処理装置の障害処理システムを得ることができる。

なお、この実施の形態では、各プロセッサコア内の登録領域にプロセッサコア上で動作するＯＳ自身の障害処理手段を登録するようにしたが、これを登録せずに、障害発生時での待ちキューに他プロセッサコアの待ちがない場合には直接自身の障害処理手段を呼び出すようにしてもこの実施の形態と同様な情報処理装置の障害処理システムを得ることができる。

この発明は、複数のプロセッサコアを搭載し、それぞれのプロセッサコアがメモリを共有し、多数のアプリケーションソフトウェア処理を並列に同時実行させることができるようなハードウェア構成における情報処置装置のアプリケーションソフトウェアの障害処理システムに利用可能である。

この発明の実施の形態１における情報処理装置のハードウェア構成図である。 実施の形態１における情報処理装置のソフトウェア構成図である。 実施の形態１における情報処理装置のＯＳ初期化時の動作の説明図である。 実施の形態１における情報処理装置のＯＳ初期化時の動作フローチャートである。 実施の形態１における情報処理装置の障害発生時の動作の説明図である。 実施の形態１における情報処理装置の障害発生時の動作フローチャートである。 実施の形態２におけるソフトウェアの構成を示す図である。 実施の形態２における情報処理装置のＯＳ初期化時の動作説明図である。 実施の形態２における情報処理装置のＯＳ初期化時の動作フローチャートである。 実施の形態２における情報処理装置の障害発生時の動作フローチャートである。 実施の形態２におけるプロセッサコアでＡＰ２２の動作状況説明図である。 実施の形態２におけるプロセッサコアでＡＰ２２の障害発生動作状況説明図である。 実施の形態２におけるプロセッサコアでＡＰ２２の障害処理終了状況説明図である。 実施の形態３におけるソフトウェアの構成を示す図である。 実施の形態３における収集領域情報内容の説明図である。 実施の形態３における情報処理装置の障害発生時の動作の説明図である。 実施の形態３における情報処理装置の障害発生時の動作フローチャートである。 実施の形態４における情報処理装置のソフトウェアの構成を示す図である。 実施の形態４における情報処理装置の障害発生時の動作説明図である。 実施の形態４における情報処理装置の障害発生時の動作フローチャートである。 実施の形態４における情報処理装置の共有メモリ領域が書込み禁止設定時の動作説明図である。 実施の形態４における情報処理装置の共有メモリ領域が書込み禁止設定時の動作フローチャートである。 実施の形態５における情報処理装置のソフトウェアの構成を示す図である。 実施の形態５における情報処理装置のＯＳ初期化時の動作説明図である。 実施の形態５における情報処理装置のＯＳ初期化時の動作フローチャートである。 実施の形態５における情報処理装置の定常状態の動作説明図である。 実施の形態５における情報処理装置の定常状態の動作フローチャートである。 実施の形態５における情報処理装置の定常状態の動作説明図である。 実施の形態５における情報処理装置の障害発生時の動作フローチャートである。

符号の説明

１、２、３；プロセッサコア、４；バス、５；メモリ、６；コンソール、７；ハードディスク装置（ＨＤＤ）、８；バックアップメモリ、９、１０、１１；演算処理部、１２、１３、１４；キャッシュ、１５、１６、１７；プロセッサ間通信機能、１８、１９、２０；ＭＭＵ、２１、２４、１２１：ＯＳ、２２、２３、２５、２６、１２２，１２３；ＡＰ、２７；ＯＳ２１用領域、２８；ＯＳ２４用領域、２９、３０、３１、３２、１３３、１３４；ＡＰ情報領域、３３、３７、１２４；ＯＳ初期化手段、３４、３８、１２５；障害処理手段、３５、３９、１２６；障害検出手段、３６、４０、１２７；プロセス切替手段、４１；コアファイル、４２；エラー情報格納域、４３；障害処理登録手段、４４、１１１、１２８；障害管理手段、４５、１０２、１１２、１２９；登録領域、４９；プロセッサコア２用領域、５０；ＡＰ２２アドレス空間、５１；ＡＰ２３アドレス空間、５２、５３、５６、５７、５９；ページテーブル、５４；ＡＰ２５アドレス空間、５５；ＡＰ２６アドレス空間、５８；テキスト／データ領域、６０；障害処理手段アドレス、７０、７１；ＯＳ内部情報、７２；収集領域情報、８０、８１；読み書き管理手段、８２、８３；共有メモリ領域、８４；空きメモリ領域、１０１；障害管理手段、１０３、１１３、１３０；アイドル状態検出手段、１０４、１１４、１３１；非アイドル状態検出手段、１３２；ＯＳ１２１用領域、１３５；待ちキュー、１３６，１３７；待ち。

Claims (7)

1. メモリを共有し、夫々オペレーティングシステム（以下ＯＳと称す）が動作する複数のプロセッサコアを備え、上記各ＯＳ上で複数のアプリケーションソフトウェア（以下ＡＰと称す）が動作する情報処理装置の障害処理システムであって、
   上記複数のプロセッサコアの何れか１つを、
   他プロセッサコア上のＯＳに対する障害処理手段を登録する登録手段と、
   他プロセッサコア上のＯＳに対する障害処理手段を登録する登録領域と、
   他プロセッサコアからの通知により、そのプロセッサコアに対応した障害処理手段を起動し実行する管理手段を備え、他プロセッサコアの各ＯＳ障害を専用に処理する障害処理専用プロセッサコアとし、
   他プロセッサコア上のＯＳは、
   障害処理専用プロセッサコア上で自ＯＳの障害処理を実施するため、ＯＳ初期化時に、自ＯＳの障害処理を実施する手段を障害処理専用プロセッサコアに登録依頼する初期化手段と、
   自ＡＰに障害が発生した際、障害発生ＡＰを停止し、障害処理専用プロセッサコアに障害発生ＡＰを通知するとともに、他ＡＰに動作を切替え、障害処理専用プロセッサコアからの障害処理完了通知後、障害発生ＡＰを再開または削除する検出手段を備えることを特徴とする情報処理装置の障害処理システム。
2. 各プロセッサコアは、メモリを分割し、分割された各メモリを異なるアドレス空間として管理するＭＭＵ（Ｍｅｍｏｒｙ Ｍａｎａｇｅｍｅｎｔ Ｕｎｉｔ）を備え、
   障害処理専用プロセッサコアは、
   登録手段は、障害処理手段のアドレスを登録する手段であり、
   登録領域は、障害処理手段のアドレスを登録する領域であり、
   管理手段は、他プロセッサからの通知により、そのプロセッサコア上で動作していたＡＰのアドレス空間に、該プロセッサコアのＭＭＵを切り替え、通知されたプロセッサコア上で動作していたＯＳ上の障害処理手段のアドレスを元に、障害処理手段を実行する手段であり、
   他プロセッサコア上のＯＳの
   初期化手段は、障害処理手段のアドレスを登録依頼する手段であり、
   検出手段は、ＡＰに障害が発生した時、障害発生ＡＰを停止し、障害発生ＡＰのアドレス空間情報を付加して障害処理専用プロセッサコアに通知するとともに、他ＡＰに動作を切替、障害処理専用プロセッサコアからの障害処理完了通知後、障害発生ＡＰを再開または削除する手段であることを特徴とする請求項１記載の情報処理装置の障害処理システム。
3. 各プロセッサコアのＯＳは、メモリ上に備える自ＯＳ用領域にページテーブル領域を備え、障害処理専用プロセッサコアに通知する障害発生ＡＰのアドレス空間情報は、不連続なメモリ領域を１つの連続した仮想アドレス空間として見せることができるページテーブル領域の先頭アドレスが付加されることを特徴とする請求項２記載の情報処理装置の障害処理システム。
4. 上記メモリは、各プロセッサコア毎に、収集する障害情報のメモリ上の領域と保存先情報を格納する領域を有し、
   障害処理専用プロセッサコアは、他プロセッサコアからの通知により、メモリの情報を元に、メモリ上の領域を保存先に保存する手段、
   他プロセッサコア上のＯＳの検出手段は、ＡＰに障害が発生した際、メモリ上の収集すべき領域の情報と、保存先の情報をメモリの自プロセッサコアの領域に保存してから、障害処理専用プロセッサコアに通知するとともに、他ＡＰに動作を切替、障害処理専用プロセッサコアからの障害処理完了通知後、障害発生ＡＰを再開または削除する手段であることを特徴とする請求項１記載の情報処理装置の障害処理システム。
5. 各ＯＳは、
   障害発生時に、各ＡＰが同じメモリ領域を操作できる共有メモリ領域に対し、書込みをした際にトラップが発生するように設定する手段、
   ＡＰ動作中に共有メモリへの書込みでトラップが発生した際に、空きメモリ領域に、書き込もうとした共有メモリの内容をコピーし、コピーした領域を、動作していたＡＰのアドレス空間に共有メモリ領域として設定する手段を備えたことを特徴とする請求項１記載の情報処理装置の障害処理システム。
6. 書込みに対するトラップ発生の設定は、各ＡＰ毎に備える、不連続なメモリ領域を１つの連続した仮想アドレス空間として見せることができるページテーブルに対し、書込み禁止の情報を付加することにより、各ＡＰ毎に書込みトラップを発生させるか否かを選択できることを特徴とする請求項５記載の情報処理装置の障害処理システム。
7. メモリを共有し、夫々ＯＳが動作する複数のプロセッサコアを備え、上記各ＯＳ上で複数の以下ＡＰが動作する情報処理装置の障害処理システムであって、
   各プロセッサコアは自プロセッサコアの処理待ちを管理する待ちキューを備えるとともに、各ＯＳは、
   他プロセッサコア上のＯＳに対する障害処理手段を登録する手段、
   他プロセッサコア上のＯＳに対する障害処理手段を登録する領域、
   他プロセッサコアからの通知による、そのプロセッサコアに対応した障害処理手段を起動する手段、
   自ＯＳの障害処理を実施する手段、
   ＯＳ初期化時に、自ＯＳの障害処理を実施する手段を他プロセッサコアに登録依頼する手段、
   動作すべきＡＰが存在しない場合に、待ちキューに自プロセッサコアの情報を繋げる手段、
   動作すべきＡＰが存在した場合に、待ちキューから自プロセッサコアの待ちを削除する手段、
   ＡＰに障害が発生した際、障害ＡＰを停止し、待ちキューからプロセッサコア情報を取得し、取得したプロセッサコアに通知するとともに、他ＡＰに動作を切替、通知したプロセッサコアからの障害処理完了通知後、障害発生ＡＰを再開または削除する手段を備えることを特徴とする情報処理装置の障害処理システム。

Images