JP5742908B2 - マルチコアプロセッサシステム、制御方法および制御プログラム - Google Patents

Description

この発明は、プロセッサに搭載された揮発性メモリに格納されているデータを復元するマルチコアプロセッサシステム、制御方法および制御プログラムに関する。

従来より、マルチコアプロセッサにおける低消費電力技術として、プロセッサ全体の負荷が軽いときには、現在利用されていないプロセッサの電源を切って消費電力を削減する手法が開示されている（たとえば、下記特許文献１，２参照）。

さらに、各ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）がローカルメモリを搭載したマルチコアプロセッサでは、プロセッサの電源を切るときに同時に各ＣＰＵと対になっているローカルメモリの電源も切る手法と、プロセッサの電源を切ってもローカルメモリの電源は入れたままにする手法が用いられている。近年では、特にローカルメモリの容量増加に伴ってローカルメモリの消費電力が増加する傾向にあるため、電力効率の観点から、プロセッサの電源切断に伴ってローカルメモリの電源も落とす手法が広く採用されている。

一般的にプロセッサ内部のレジスタやローカルメモリは、揮発性メモリによって構成されており、電源が供給されている状態でなければ内部の情報が保持されない。そこで、通常は、オペレーティングシステム（以下、「ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）」と呼ぶ）等により、電源を切る前にプロセッサのレジスタおよびローカルメモリに格納されているデータを、共有メモリなどの電源が切られないプロセッサ外部の記憶装置に待避する処置が施される。

ローカルメモリなど、揮発性メモリに格納されていたデータを、共有メモリに待避させることによって、ＣＰＵ内のキャッシュをフラッシュしてデータが消えたとしても問題なく利用することができる。そして、電源が再投入された時に、ＯＳ等により待避されたデータが共有メモリから読み出され、ローカルメモリに復元される。

また、最近では、ハードディスクなどの格納データの安全性を保持するための技術として広く活用されているＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）技術を、ローカルメモリの待避に応用することで電源切断によるデータの消滅を回避する例も開示されている（たとえば、下記特許文献３，４）。

ＲＡＩＤ技術を利用した場合、ローカルメモリに格納されているデータを他のメモリに分散して格納する。したがって、ＣＰＵの電源停止に伴ってローカルメモリの電源が停止されても、他のメモリに格納されたデータを利用して、消去されてしまったデータを復元することができる。

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

しかしながら、近年の微細化技術の進歩に伴ってローカルメモリの容量が増加し、レジスタやキャッシュに比べて待避にかかる時間の増加が著しく、電力効率の悪化に大きく影響する可能性が高くなっている。たとえば、レジスタやキャッシュの容量は、数十〜数百バイト、もしくは数十キロバイトであるが、ローカルメモリの容量は数百キロバイトに及ぶものも多い。したがって、ローカルメモリに格納されているデータを待避させるまでの電力量を考慮すると、低消費電力技術を採用したにもかかわらず、十分な効果が得られないという問題があった。

また、上述のような揮発性メモリ内のデータの待避処理に対する解決策として、ＲＡＩＤ技術が挙げられているが、ＲＡＩＤによってデータを分散するハードディスクとマルチコアプロセッサのローカルメモリとの構成の違いが考慮されていないため、十分な効果を得るに至ってない。

本来、ＲＡＩＤ技術によるデータの復元はハードディスクドライブの故障を前提とした技術である。具体的には、従来のＲＡＩＤ技術では１つか２つのＨＤＤ（Ｈａｒｄ ｄｉｓｋ Ｄｒｉｖｅ）が停止することを想定してデータを分散させたり、復元用の冗長データを生成したりする構成になっている。

一方、マルチコアプロセッサにおける電源制御の場合、複数のローカルメモリの電源を停止することがある。したがって、従来のＲＡＩＤ技術の延長ではローカルメモリの電源制御に対応して消滅したデータを復元するような運用は困難であった。

本開示技術は、上述した従来技術による問題点を解消するため、揮発性メモリに格納されたデータの待避を待たずに高速な電源停止を可能にするマルチコアプロセッサシステム、制御方法および制御プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、本開示技術は、複数のコアと、複数のコアそれぞれに対応してデータを記録する複数のローカルメモリと、複数のコアが共通にアクセス可能な共有メモリと、複数のローカルメモリに記録されたデータを共有メモリに復元するデータ復元装置とを有するマルチプロセッサシステムであって、データ復元装置が、複数のコアのうちの第１のコアに対応する第１のローカルメモリへの電源供給停止に応じ、第１のローカルメモリを除く複数のローカルメモリに記録されたパリティデータに基づいて、電源供給停止前に第１のローカルメモリに記録されていたデータを共有メモリに復元する。

本マルチコアプロセッサシステム、制御方法および制御プログラムによれば、揮発性メモリに格納されたデータの待避を待たずに高速な電源停止を可能にするという効果を奏する。

図１は、本実施の形態にかかるデータ復元処理の一例を示す説明図である。 図２は、ＲＡＩＤ技術を利用したマルチコアプロセッサの構成例を示す説明図である。 図３は、ＲＡＩＤ１の運用を示す説明図である。 図４は、ＲＡＩＤ５の運用を示す説明図である。 図５は、データ復元装置のハードウェア構成を示すブロック図である。 図６は、データ復元装置の機能的構成を示すブロック図である。 図７は、データ復元装置によるデータ復元処理の手順を示すフローチャートである。 図８は、ＲＡＩＤコントローラを備えたマルチコアプロセッサの構成例を示すブロック図である。 図９は、実施例１におけるＲＡＩＤコントローラの内部構成例を示すブロック図である。 図１０は、通常時の動作例を示す説明図である。 図１１は、通常時のＲＡＩＤコントローラの動作手順を示すフローチャートである。 図１２は、電源停止時の動作例を示す説明図である。 図１３は、実施例１における電源停止時のＯＳの動作手順を示すフローチャートである。 図１４は、電源停止時のＲＡＩＤコントローラによる動作手順を示すフローチャートである。 図１５は、ＣＰＵ＃１の停止動作の手順（その１）を示す説明図である。 図１６は、ＣＰＵ＃１の停止動作の手順（その２）を示す説明図である。 図１７は、ＣＰＵ＃１の停止動作の手順（その３）を示す説明図である。 図１８は、ＣＰＵ＃１の停止動作の手順（その４）を示す説明図である。 図１９は、電源停止中のローカルメモリへのアクセス例を示す説明図である。 図２０は、電源停止中のＲＡＩＤコントローラによるアクセス手順を示すフローチャートである。 図２１は、電源停止中のローカルメモリへの読込手順（その１）を示す説明図である。 図２２は、電源停止中のローカルメモリへの読込手順（その２）を示す説明図である。 図２３は、電源停止中のローカルメモリへの書込手順（その１）を示す説明図である。 図２４は、電源停止中のローカルメモリへの書込手順（その２）を示す説明図である。 図２５は、電源復帰時の動作例を示す説明図である。 図２６は、実施例１における電源復帰時のＯＳの動作手順を示すフローチャートである。 図２７は、電源復帰時のＲＡＩＤコントローラによる動作手順を示すフローチャートである。 図２８は、ＣＰＵ＃１の復帰動作の手順（その１）を示す説明図である。 図２９は、ＣＰＵ＃１の復帰動作の手順（その２）を示す説明図である。 図３０は、復元中のローカルメモリへのアクセス例を示す説明図である。 図３１は、復元中のＲＡＩＤコントローラによるアクセス手順を示すフローチャートである。 図３２は、復元中のＣＰＵ＃１への読込動作の手順（その１）を示す説明図である。 図３３は、復元中のＣＰＵ＃１への読込動作の手順（その２）を示す説明図である。 図３４は、復元中のＣＰＵ＃１への読込動作の手順（その３）を示す説明図である。 図３５は、復元中のＣＰＵ＃１への書込動作の手順（その１）を示す説明図である。 図３６は、復元中のＣＰＵ＃１への書込動作の手順（その２）を示す説明図である。 図３７は、アクセス監視バスを備えたマルチコアプロセッサの構成例を示す説明図である。 図３８は、実施例２におけるＲＡＩＤコントローラの内部構成を示すブロック図である。 図３９は、実施例２における電源停止時のＯＳの動作手順を示すフローチャートである。 図４０は、コマンド受信部の動作手順を示すフローチャートである。 図４１は、実施例２におけるデータ待避部の動作手順を示すフローチャートである。 図４２は、実施例２における復元データ生成部の動作手順を示すフローチャートである。 図４３は、パリティ再構築部の動作手順を示すフローチャートである。 図４４は、パリティ生成部の動作手順を示すフローチャートである。 図４５は、実施例２における電源復帰時のＯＳの動作手順を示すフローチャートである。 図４６は、データ復帰部の動作手順を示すフローチャートである。 図４７は、実施例３における電源復帰時のＯＳの動作手順を示すフローチャートである。 図４８は、実施例３におけるＲＡＩＤコントローラの内部構成を示すブロック図である。 図４９は、メモリアクセス監視部の動作手順を示すフローチャートである。 図５０は、実施例３におけるデータ待避部の動作手順を示すフローチャートである。 図５１は、実施例３における復元データ生成部の動作手順を示すフローチャートである。 図５２は、データ復元処理を採用した場合の電力比較例を示す説明図である。

以下に添付図面を参照して、この発明にかかるマルチコアプロセッサシステム、制御方法および制御プログラムの好適な実施の形態を詳細に説明する。

図１は、本実施の形態にかかるデータ復元処理の一例を示す説明図である。図１に示すように、マルチコアプロセッサ１００は、複数のＣＰＵ（たとえば、ＣＰＵ＃０〜ＣＰＵ＃３）を備えたプロセッサ群である。マルチコアプロセッサ１００は、複数のＣＰＵ以外に、電源１０１と、ローカルメモリバス１０２と、共有メモリバス１０３とを備えている。

電源１０１は、各ＣＰＵおよび各ＣＰＵがアクセスするローカルメモリに電力を供給する。また、電源１０１は、ＯＳからの指示に応じて、指定されたＣＰＵおよびローカルメモリのみの電力の供給を停止することが可能である。同様に、電源１０１は、ＯＳからの指示に応じて、指定されたＣＰＵおよびローカルメモリのみの電力の供給を復帰させることもできる。また、各ＣＰＵはＯＳによって制御されるが、ＣＰＵが停止中は対応するＯＳも停止中になる。したがって、各ＯＳは自ＣＰＵの電源のＯＦＦを制御すると共に、他ＣＰＵの電源のＯＮを制御する。

ローカルメモリバス１０２は、各ＣＰＵとローカルメモリとのアクセスを可能にするバスである。また、各ＣＰＵは、ローカルメモリバス１０２を経由して他のプロセッサのローカルメモリにもアクセスすることができる。

共有メモリバス１０３は、マルチコアプロセッサ１００と共有メモリ１０４とのアクセスを可能にするバスである。共有メモリ１０４は、不揮発性メモリもしくは、常時電力が供給されるデータ消失の恐れのないメモリである。

本実施の形態の場合、図１のように、上述したような構成のマルチコアプロセッサ１００に、データ復元装置１１０を追加することによって、ＣＰＵと共にローカルメモリへの電力供給が停止されても、ローカルメモリ内のデータを復元することができる。

（従来の電源停止・始動手順）
本実施の形態にかかるデータ復元処理を説明する前に、従来のマルチコアプロセッサの電源停止および始動の手順について説明する。

従来の電源停止時では、マルチコアプロセッサ１００にデータ復元装置１１０が備わっておらず、停止対象となるＣＰＵのＯＳ（たとえば、ＣＰＵ＃０のＯＳ）が電源停止処理を開始する。ＯＳは、まず、停止対象のＣＰＵのレジスタとローカルメモリ内のデータを共有メモリ１０４に待避させる。次に、ＯＳは、キャッシュの内容を共有メモリ１０４に書き戻す。続いて、ＯＳは、他のＣＰＵのＯＳへ電力停止を通知する。最後に、ＯＳから電源１０１へ電力供給の停止指示が行われ、電源が切られる。

次に、従来の電源始動時では、稼働中のＣＰＵのＯＳ（たとえば、ＣＰＵ＃１のＯＳ）が停止中のＣＰＵの電源復帰処理を開始する。ＯＳは、まず、電源１０１に対して復帰させるＣＰＵへの電力供給の始動指示を行い、電源を入れる。次に、ＯＳは、共有メモリ１０４に待避したレジスタおよびローカルメモリのデータを復帰させたＣＰＵのレジスタおよびローカルメモリ内に復元する。

以上説明したように、従来の電源停止の場合には、ローカルメモリ内のデータを共有メモリ１０４に待避するまで、ローカルメモリへの電力供給の停止を待機しなければならなない。同様に、電源始動の場合にも、電源停止の際に共有メモリ１０４にローカルメモリ内のデータが待避されている場合には、すべてのデータをローカルメモリ内に復元するまで、ＣＰＵは通常の動作に移行することはできない。

（ＲＡＩＤ技術）
図２は、ＲＡＩＤ技術を利用したマルチコアプロセッサの構成例を示す説明図である。従来の電源停止の際のデータの待避時間を省略するための対策案として、ＲＡＩＤ技術が利用されることがある。具体的には、電源停止時にローカルメモリのデータを回避しなくても、冗長化したデータから停止されたＣＰＵのローカルメモリに格納されていたデータを復元することができる。

図２に例示したマルチコアプロセッサ２００の場合、ＣＰＵ＃１が停止しても、ローカルメモリ０に格納されたＤＡＴＡ１と、ローカルメモリ２に格納されたＤＡＴＡ３と、ローカルメモリ３に格納されたＰａｒｉｔｙ１によってＤＡＴＡ２を復元することができる。同様に、ＤＡＴＡ６についても、ローカルメモリ０，２，３にそれぞれ格納されたＤＡＴＡ５、Ｐａｒｉｔｙ２、ＤＡＴＡ４によって復元することができる。

図３は、ＲＡＩＤ１の運用を示す説明図であり、図４は、ＲＡＩＤ５の運用を示す説明図である。ＲＡＩＤ技術とは、複数のハードディスクドライブ（以下、「ＨＤＤ」と呼ぶ）を仮想的な１台のＨＤＤとして運用する技術である。ＲＡＩＤ技術の中には図３に示したＲＡＩＤ１のように、１つのデータ（たとえばデータＡ）を、ＲＡＤＩコントローラによって、複数のＨＤＤにそれぞれ格納するミラーリングがある。

また、図４に示したＲＡＤＩ５のように、格納用のデータ（たとえばデータＡ〜Ｆ）の他に、冗長データ（パリティデータ（たとえばＰａｒ１やＰａｒ２））を分散して格納する。いずれかのＨＤＤが破損したとしても、パリティデータを利用して半損したデータを復元することができる。

具体的には、下記のように破損したＨＤＤ以外のＨＤＤに格納されている各データ同士の排他的論理和を求めることによって破損したＨＤＤに格納されていたデータを復元する。

Ｐａｒ１ ＝ＡｘｏｒＢｘｏｒＣ
Ａ ＝ＢｘｏｒＣｘｏｒＰａｒ１
Ｂ ＝ＡｘｏｒＢｘｏｒＰａｒ１
Ｃ ＝ＢｘｏｒＣ ｘｏｒＰａｒ１
Ｐａｒ２ ＝ＤｘｏｒＥｘｏｒＦ
Ｄ ＝ＥｘｏｒＦｘｏｒＰａｒ２
Ｅ ＝ＤｘｏｒＦｘｏｒＰａｒ２
Ｆ ＝ＢｘｏｒＣｘｏｒＰａｒ２

上述したいずれの手法もＨＤＤに格納するデータを冗長化することによって予期せぬＨＤＤの故障からデータを保護することができる。したがって、従来より、ＲＡＩＤ５やＲＡＩＤ５に類似したＲＡＩＤ６を利用してＣＰＵのローカルメモリなど揮発性メモリに格納されたデータを保護する手法があった。

ところが、マルチコアプロセッサ１００のように、複数のローカルメモリに格納されたデータをＲＡＩＤ５の手法によって分散すると、複数のＣＰＵが停止中になってしまうような事態には対応できない可能性が高い。

ＲＡＩＤ技術の場合、複数のＨＤＤの中の１つのＨＤＤが故障した場合に残りのＨＤＤに格納されたデータを利用して故障したＨＤＤに格納されたデータを復元する。したがって、同じ手法をマルチコアプロセッサに適用すると、複数のＣＰＵの電源が停止された場合には、ローカルメモリに格納されたデータを復元することができない。

ＲＡＩＤ５の手法におけるパリティデータを多数作成して複数のＣＰＵが停止してもローカルメモリに格納されていたデータを復元することも可能ではあるが、ローカルメモリにおけるパリティデータの比率が増し、ＣＰＵが使用できる領域を縮小させてしまう。

そこで、本実施の形態では、ローカルメモリへの電力供給が停止後に、停止したローカルメモリの内容をパリティデータから復元して、共有メモリ１０４に待避すると共に、稼働中のローカルメモリの構成に合わせて、新たなパリティデータを再構築する。

図１に戻って説明すると、データ復元装置１１０は、ＣＰＵ＃１およびローカルメモリ１への電力供給が停止した後、冗長データからローカルメモリの内容を共有メモリ１０４上に復元する（ステップＳ２０１）。具体的には、ローカルメモリ１に格納されていたＤＡＴＡ２がＤＡＴＡ１、ＤＡＴＡ３およびＰａｒｉｔｙ１によって復元され共有メモリ１０４内の待避領域＃１に格納される。なお、実際には続いて、ローカルメモリ１に格納されていたＤＡＴＡ６についても同様に、ＤＡＴＡ５、ＤＡＴＡ３、ＤＡＴＡ４およびＰａｒｉｔｙ２によって復元されるが、ここでは説明を省略する。

ステップＳ２０１の復元後、データ復元装置１１０は、稼働中のＣＰＵの数に応じてパリティデータを再構築する（ステップＳ２０２）。すなわち、ＣＰＵ＃１が停止する前は、４つのＣＰＵのローカルメモリを利用して、各ローカルメモリに格納されているデータをそれぞれ復元可能なパリティデータが格納されていた。ところが、ＣＰＵ＃１が停止してしまった。そこで、ＣＰＵ＃１の停止後は、稼働中の３つのＣＰＵのローカルメモリを利用して、各ローカルメモリに格納されているデータをそれぞれ復元可能なパリティデータを生成（再構築）して、ローカルメモリに、それぞれ格納する。

パリティデータの再構築後であれば、さらに別のＣＰＵのローカルメモリの電源を止めても、再構築後のパリティデータからデータを復元できるため、同様の手順を行うことで複数のローカルメモリの電源停止に対応できる。したがって、ローカルメモリの電源停止時に事前にローカルメモリの内容を待避しておく必要がなくなるため、ローカルメモリの電源停止動作を高速化することができる。

以下に、図１に例示したような高速な電源停止を実現するためのデータ復元装置１１０の具体的な構成例および処理手順について説明する。

（データ復元装置のハードウェア構成）
図５は、データ復元装置のハードウェア構成を示すブロック図である。図５において、データ復元装置１１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）５０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）５０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）５０３と、磁気ディスクドライブ５０４と、磁気ディスク５０５と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）５０６と、を備えている。また、各構成部はバス５００によってそれぞれ接続されている。

ここで、ＣＰＵ５０１は、データ復元装置の全体の制御を司る。ＲＯＭ５０２は、ブートプログラムや、データ復元処理を実現するためのデータ復元プログラムなどの各種プログラムを記憶している。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。磁気ディスクドライブ５０４は、ＣＰＵ５０１の制御にしたがって磁気ディスク５０５に対するデータのリード／ライトを制御する。磁気ディスク５０５は、磁気ディスクドライブ５０４の制御で書き込まれたデータを記憶する。なお、記憶媒体として図５の例では磁気ディスク５０５を挙げたが、光ディスクや半導体メモリなど他の媒体を利用してもよい。

インターフェース（以下、「Ｉ／Ｆ」と略する。）５０６は、所定の通信規格に応じたバスによって、マルチコアプロセッサ内の各ＣＰＵや、各ＣＰＵがアクセスする揮発性メモリ（ローカルメモリ）、また、共有メモリ１０４との相互通信を実現する。

（データ復元装置の機能的構成）
図６は、データ復元装置の機能的構成を示すブロック図である。データ復元装置１１０は、停止検出部６０１と、復元部６０２と、作成部６０３と、格納部６０４と、始動検出部６０５と、復帰部６０６と、を含む構成である。この制御部となる機能（停止検出部６０１〜復帰部６０６）は、具体的には、たとえば、図５に示したＲＯＭ５０２、ＲＡＭ５０３、磁気ディスク５０５などの記憶装置に記憶されたプログラムをＣＰＵ５０１に実行させることにより、または、Ｉ／Ｆ５０６により、その機能を実現する。

停止検出部６０１は、ＯＳなどの上位プログラムからプロセッサへの停止指示を検出する機能を有している。具体的には、停止検出部６０１は、マルチコアプロセッサ６００内の複数のプロセッサ（プロセッサ０〜プロセッサｎ）の中のいずれかのプロセッサへの停止指示を検出する。なお、検出結果は、ＲＡＭ５０３、磁気ディスク５０４などの記憶領域に記憶される。

復元部６０２は、電力の供給が停止した揮発性メモリに格納されていたデータを共有メモリ１０４に復元する機能を有する。具体的には、復元部６０２は、検出部６０１によって停止指示が検出されると、停止指示先のプロセッサ以外の稼働中のプロセッサ群がアクセスする揮発性メモリに格納されているパリティデータに基づいて、揮発性メモリに格納されていたデータを復元する。そして、復元部６０２は、復元したデータを稼働中のプロセッサ群がアクセス可能な共有メモリ１０４内に格納する。復元されたデータは、一時的に、ＲＡＭ５０３、磁気ディスク５０５などの記憶領域に記憶される。

作成部６０３は、新たなパリティデータを作成する機能を有する。具体的には、作成部６０３は、復元部６０２によってデータの復元が実行された後に、稼働中のプロセッサ群がアクセスする揮発性メモリにそれぞれ格納されているデータを復元するパリティデータを作成する。なお、作成されたパリティデータは、ＲＡＭ５０３、磁気ディスク５０５などの記憶領域に記憶される。

格納部６０４は、作成されたパリティデータを稼働中のプロセッサの揮発性メモリに格納する機能を有する。具体的には、格納部６０４は、作成部６０３によって作成されたパリティデータを、それぞれ稼働中のプロセッサ群がアクセスする揮発性メモリにそれぞれ格納する。

このとき、格納部６０４は、パリティデータによって復元されるデータが格納されている揮発性メモリ以外の揮発性メモリに格納する。たとえば、揮発性メモリ１に格納されたデータを復元するパリティデータは、揮発性メモリ１以外の稼働中のプロセッサの揮発性メモリに格納される。

なお、作成部６０３は、複数のプロセッサの中のいずれかのプロセッサの揮発性メモリに新たにデータが追加または新たなデータに更新されると、新たなデータを復元するパリティデータを作成する。すなわち、揮発性メモリに格納されているデータが更新されると、その都度、最新のデータを復元するためのパリティデータを作成する。

したがって、格納部６０４は、作成部６０３によって作成されたパリティデータを、それぞれ稼働中のプロセッサ群がアクセスする揮発性メモリのうち、新たなデータが追加または新たなデータに更新された揮発性メモリ以外の揮発性メモリに格納する。

始動検出部６０５は、上位プログラムからのプロセッサへの指示を検出する機能を有する。具体的には、始動検出部６０５は、複数のプロセッサの中の停止中のプロセッサへの電力供給の始動を検出する。なお、検出結果は、ＲＡＭ５０３、磁気ディスク５０５なの記憶領域に記憶される。

復帰部６０６は、電力供給が開始されたプロセッサの揮発性メモリに、待避中のデータを復帰する機能を有する。具体的には、復帰部６０６は、始動検出部６０５によって電力供給の始動が検出された場合、共有メモリ１０４に復元されたデータを、電力供給の始動が検出されたプロセッサがアクセスする揮発性メモリに格納する。

また、復元部６０２によるデータの復元中に、始動検出部６０５によって、電力供給の始動が検出された場合、揮発性メモリに格納されていたデータのうち、共有メモリ１０４に復元されていないデータがある。これらのデータについて、復帰部６０６は、稼働中のプロセッサ群がアクセスする揮発性メモリに格納されているパリティデータを用いて復元して復帰させる。

作成部６０３は、上述した復帰部６０６によってデータが復元された場合には、稼働中のプロセッサ群がアクセスする揮発性メモリにそれぞれ格納されているデータを復元するパリティデータを作成する。また、格納部６０４は、作成部６０３によって作成されたパリティデータを、パリティデータによって復元されるデータが格納されている揮発性メモリ以外の揮発性メモリに格納する。すなわち、揮発性メモリ１に格納されていたデータを復元するパリティデータは、揮発性メモリ１以外の稼働中の揮発性メモリ群に格納される。

また、データ復元装置１１０は、上述した停止検出部６０１や始動検出部６０５の検出機能に加えて、いずれかのプロセッサから揮発性メモリに格納されているデータに対する読込要求を検出する読込検出機能を用意してもよい。

具体的には、読込検出機能によって、読込要求が検出されたデータが格納されている揮発性メモリが稼働中でない場合、データ復元装置１１０は、データが共有メモリ１０４に格納されていることをデータの読込を実行するプロセッサに通知する。通知を受けたプロセッサは、通知に基づいて所望のデータが格納されていない揮発性メモリではなく、実際に所望のデータが格納されている共有メモリ１０４に格納されているデータを読み込むことができる。

また、停止中の揮発性メモリに格納されていたデータに対して、共有メモリ１０４に復元する前に読込要求が発生した場合がある。上述のような場合、データ復元装置１１０は、復元部６０２の機能を利用して、パリティデータに基づいて、停止中の揮発性メモリに格納されていたデータを復元する。さらに、データ復元装置１１０は、復元したデータの格納先を、データの読込を実行するプロセッサに通知することによって、所望するデータを読み込ませることができる。

またデータ復元装置１１０は、さらに、稼働中のプロセッサ数に応じて、本実施の形態にかかるデータ復元処理と、従来のデータ待避処理とのいずれかを選択的に適用させてもよい。稼働中のプロセッサ数が極端に少なくなってしまうと、稼働中の揮発性メモリの容量に占めるパリティデータ量の割合が増してしまう。すなわち、プロセッサが本来の処理に利用できる揮発性メモリの容量が小さくなり、プロセッサの機能低下を招いてしまい、結果として電力効率が悪化してしまう。

そこで、データ復元装置１１０を適用するマルチコアプロセッサ６００のプロセッサの総数や、揮発性メモリの容量に応じて、あらかじめ定めたＣＰＵ数の規定値をしきい値として、しきい値を基準に本実施の形態にかかるデータ復元処理と、従来のデータ待避処理とのいずれを利用するか自動的に判断する構成にすることもできる。しきい値を利用した判断を行うことによって、データ復元装置１１０は、マルチコアプロセッサ６００内の各プロセッサの稼働状況に応じて、最も電力効率のよい動作となるように支援することができる。

具体的には、たとえば、マルチコアプロセッサ６００によって実行中のＯＳによって、稼働中のプロセッサの数がしきい値以上か否かを判断する処理を実行させる。そして、プロセッサが、マルチコアプロセッサ６００のいずれかのプロセッサへの停止指示を受け付けると、稼働中のプロセッサの数がしきい値以上と判断された場合、ＯＳは、停止指示が受け付けられたプロセッサおよび当該プロセッサがアクセスする揮発性メモリへの電力供給の停止指示を電源１０１に出力して、即座に電力供給を停止する。

すなわち、データ復元装置１１０では、本実施の形態にかかるデータ復元処理を実行させるため、揮発性メモリへの電力供給が停止しても、格納されていたデータは、共有メモリ１０４内に復元される。

一方、稼働中のプロセッサの数がしきい値以上ではないと判断された場合、パリティデータ量が大きくなってしまう。そこで、ＯＳは、従来技術と同様に、揮発性メモリ内のデータを共有メモリ１０４に待避させるまで電力供給の停止を待つ。

具体的には、ＯＳは、マルチコアプロセッサ６００に、稼働中のプロセッサの数がしきい値以上ではないと判断された場合、停止指示が受け付けられたプロセッサの揮発性メモリに格納されているデータを共有メモリ１０４に転送する。また、ＯＳは、上述の転送によって揮発性メモリに格納されているデータが共有メモリ１０４に転送された後、揮発性メモリへの電力供給の停止指示を電源１０１に出力する。

（データ復元処理の手順）
図７は、データ復元装置によるデータ復元処理の手順を示すフローチャートである。図７のフローチャートは、データ復元装置１１０が、プロセッサに対する停止指示を受けた際に、揮発性メモリに格納されていたデータを自動的に復元して共有メモリ１０４に格納するまでの手順を示している。図７の各処理を実行することによって、データ復元装置１１０を備えたマルチコアプロセッサ６００は、停止指示を受けたプロセッサの揮発性メモリに格納された内容の待避処理を待つことなく、即座に電源を停止することができる。

図７において、データ復元装置１１０は、まず、停止検出部６０１によって停止指示を検出したか否かを判断する（ステップＳ７０１）。ステップＳ７０１において、停止指示を検出したと判断された場合（ステップＳ７０１：Ｙｅｓ）、データ復元装置２０は、ステップＳ７０４の処理に移行し、停止対象となる揮発性メモリに格納されていたデータの復元処理を行う。

なお、ステップＳ７０１において、停止指示を検出していないと判断された場合（ステップＳ７０１：Ｎｏ）、データ復元装置１１０は、ＯＳが現在稼働中の揮発性メモリに対して新たなデータを格納するか否かを判断する（ステップＳ７０２）。ステップＳ７０２によって、新たなデータを格納するか否かは、マルチコアプロセッサ６００を動作させる上位のプログラム（ここではＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ））からの書込指示を受けたか否かに応じて判断される。

ステップＳ７０２において、新たなデータを格納すると判断された場合（ステップＳ７０２：Ｙｅｓ）、データ復元装置１１０は、作成部６０３によって、揮発性メモリに格納された新たなデータを復元するためのパリティデータを作成し、格納部６０４によって稼働中のプロセッサの揮発性メモリに格納される（ステップＳ７０３）。

一方、ステップＳ７０１によって停止指示を検出したと判断された場合、データ復元装置１１０は、復元部６０２によって、パリティデータを用いて停止したプロセッサの揮発性メモリに格納されていたデータを共有メモリ１０４に復元する（ステップＳ７０４）。

ステップＳ７０３，Ｓ７０４の処理が完了した後、もしくは、ステップＳ７０２において、新たなデータを格納しないと判断された場合（ステップＳ７０２：Ｎｏ）、データ復元装置１１０は、始動検出部６０５によって始動指示を検出したか否かを判断する（ステップＳ７０５）。

ステップＳ７０５によって始動指示を検出した場合（ステップＳ７０５：Ｙｅｓ）、データ復元装置１１０は、復帰部６０６によって、共有メモリ１０４にステップＳ７０４によって復元したデータを、始動したプロセッサの揮発性メモリに復帰する（ステップＳ７０６）。一方、ステップＳ７０５によって始動指示を検出しなかった場合（ステップＳ７０５：Ｎｏ）、ステップＳ７０６の処理を行わずに、ステップＳ７０７の処理に移行する。

その後、データ復元装置１１０は、ＯＳなどの上位システムから終了指示を受けたか否かを判断する（ステップＳ７０７）。データ復元装置１１０は、終了指示を受けなければ（ステップＳ７０７：Ｎｏ）、ステップＳ７０１〜Ｓ７０６までの処理を繰り返す。そして、ステップＳ７０７において、データ復元装置１１０は、終了指示を受けると（ステップＳ７０７：Ｙｅｓ）、そのまま一連の処理を終了する。

以上説明したように、データ復元装置１１０を用意することによって、マルチコアプロセッサ６００のいずれかのプロセッサとその揮発性メモリへの電力供給を停止させても揮発性メモリに格納されていたデータを復元することができる。したがって、従来のように、揮発性メモリ内のデータの待避を考慮することなく、高速にＣＰＵを停止して消費電力を大幅に削減することができる。また、データ復元装置１１０は、マルチコアプロセッサ６００において、稼働中のプロセッサ数に応じて電源停止時のデータ待避の手法を自動的に選択させることもできる。

次に、上述したようなデータ復元処理を実現するデータ復元装置１１０の具体的な適用例として、データ復元装置１１０の機能を、ＲＡＩＤコントローラによって実現する実施例１〜３について詳しく説明する。

（実施例１）
図８は、ＲＡＩＤコントローラを備えたマルチコアプロセッサの構成例を示すブロック図である。実施例１では、ＲＡＩＤコントローラ８０１によって、データ復元装置１１０の機能を実現する。マルチコアプロセッサ８００のＲＡＩＤコントローラ８０１は、ローカルメモリバス１０２によって、各ＣＰＵとローカルメモリとが接続されている。また、各ＣＰＵもローカルメモリバス１０２を経由して他のＣＰＵのローカルメモリにアクセスできる構成になっている。

図９は、実施例１におけるＲＡＩＤコントローラの内部構成例を示すブロック図である。ＲＡＩＤコントローラ８０１は、メモリアクセス監視部９０１と、パリティ生成部９０２と、パリティ再構築部９０３と、コマンド受信部９０４と、復元データ生成部９０５と、データ待避部９０６とを備えている。

メモリアクセス監視部９０１は、ＣＰＵからローカルメモリへのアクセスを監視する。また、パリティ生成部９０２は、ローカルメモリに格納されたデータを復元するためのパリティデータを生成する。

パリティ再構築部９０３は、ローカルメモリに書込があった場合に対応するパリティデータを更新する。コマンド受信部９０４は、ＯＳから出力されたコマンドを受信してコマンドの内容に応じた処理を実行する。復元データ生成部９０５は、パリティデータを利用して、停止されたローカルメモリに格納されていたデータを共有メモリ１０４内に復元する。データ待避部９０６は、電源停止時にローカルメモリに格納されていたデータを一時的に待避させる。なお、上述した各機能部の詳細な処理手順は後述する。

なお、ローカルメモリのデータ領域は、通常のデータ領域として利用する領域と、パリティデータ領域に分割されている。また、現在稼働しているローカルメモリがＮ個有り、現在稼働しているローカルメモリの中でｍ番目のローカルメモリのアドレスｘの値を書き換えたとすると、（Ｎ×ｘ＋ｍ）／（Ｎ−１）…（１）式の整数部分が同一となるｘ，ｍの組み合わせの場所からデータを読み込んでパリティデータを生成する。

また、（Ｎ×ｘ＋ｍ）／（Ｎ−１）２…（２）式の整数部分をｙ、余りをｋとすると、Ｎ−１−ｋ番目のローカルメモリのｙ番目のアドレスにパリティデータを書き込む。なお、パリティデータの生成には幾つか手法が知られているが、ここで説明する実施例１〜３では、ＲＡＩＤ５技術と同様に排他論理和によりパリティデータを生成する。

具体的には、パリティ生成部９０２では、上記（１），（２）式から、現在稼働しているローカルメモリ数がＮでｋ番目のローカルメモリのｙ番目のアドレスにパリティデータを再構築する。そして、上記（１），（２）式から逆算して、Ｎ×ｘ＋ｍ＝（Ｎ×ｘ＋ｍ）／（Ｎ−１）を満たすｍ，ｘの組み合わせのローカルメモリ／アドレスからデータを読み込んで排他論理和によりパリティデータを生成する。

＜通常時の動作＞
図１０は、通常時の動作例を示す説明図である。まず、ＲＡＩＤコントローラ８０１の通常時の動作について説明する。図１０のように、通常時ＲＡＩＤコントローラ８０１は、稼働中のいずれかのＣＰＵからローカルメモリへのアクセスが発生すると、アクセス内容に応じて、パリティデータを生成する。

具体的には、図１０のようにＣＰＵ＃０からローカルメモリ０への書込処理が行われると、書込処理によって、ローカルメモリ０のデータの内容が更新される。このとき、メモリアクセス監視部９０１は、ＣＰＵ＃０からのアクセスを検出する。そして、検出されたアクセスが書込処理であったため、パリティ生成部９０２は、書込処理後のデータを復元するパリティデータ（Ｐａｒｉｔｙ１１，２１，３１）を生成する。生成されたパリティデータは、パリティ生成部９０２によって、ＣＰＵ＃３のパリティデータ領域に格納される。

図１１は、通常時のＲＡＩＤコントローラの動作手順を示すフローチャートである。通常時とは、マルチコアプロセッサが稼働中のＣＰＵのみの動作であり、ＣＰＵの停止や、停止中のＣＰＵの復帰などの動作が発生していない状態を意味する。

図１０において、ＲＡＩＤコントローラ８０１は、まずメモリアクセス監視部９０１において、ローカルメモリへの書込を検出する（ステップＳ１１０１）。その後、ＲＡＩＤコントローラ８０１は、パリティ生成部９０２において、まず、対応するデータを読み込み（ステップＳ１１０２）、パリティデータを生成する（ステップＳ１１０３）。その後、ＲＡＩＤコントローラ８０１は、対応するパリティデータを更新し（ステップＳ１１０４）、一連の処理を終了する。

以上説明したように、通常時ＲＡＩＤコントローラ８０１では、ローカルメモリへの書込が検出された場合には、その都度、書き込まれたデータを復元するためのパリティデータを生成し、生成されたパリティデータを最新のパリティデータとして更新しておく。したがって、どのようなタイミングで電源停止が発生しても、最新データを復元することができる。

＜電源停止時の動作＞
図１２は、電源停止時の動作例を示す説明図である。図１２に例示したように、稼働中のＣＰＵの中のいずれか１つのＣＰＵの電源停止が行われた場合、停止されたＣＰＵのローカルメモリも、格納されているデータを待避することなく、即座に電力供給が停止し、電源停止状態となる。ＲＡＩＤコントローラ８０１は、電力供給停止後に、稼働中のローカルメモリに格納されている冗長データから電源停止したローカルメモリに格納されていたデータの内容を共有メモリ１０４上に復元する（ステップＳ１２０１）。

図１３は、実施例１における電源停止時のＯＳの動作手順を示すフローチャートである。図１３のフローチャートは、電源停止時にＯＳからＲＡＩＤコントローラ８０１へ出力される指示内容と、その手順を表している。

図１３において、ＯＳはまず、稼働中のＣＰＵ数が規定値以下か否かを判断する（ステップＳ１３０１）。ステップＳ１３０１において、稼働中のＣＰＵ数が規定値以下でないと判断された場合（ステップＳ１３０１：Ｎｏ）、ＯＳは、パリティデータが再構築中か否かを判断する（ステップＳ１３０２）。

ステップＳ１３０２において、パリティが再構築中であると判断された場合（ステップＳ１３０２：Ｙｅｓ）、ＯＳは、再構築中が完了するまで待ち（ステップＳ１３０３）、レジスタの内容を共有メモリ１０４に待避させる（ステップＳ１３０４）。なお、ステップＳ１３０２において、パリティが再構築中ではないと判断された場合（ステップＳ１３０２：Ｎｏ）、ステップＳ１３０３によって待機することなく、ステップＳ１３０４の処理に移行する。

その後、ＯＳは、キャッシュをフラッシュして（ステップＳ１３０５）、ＲＡＩＤコントローラ８０１に対象となるＣＰＵの停止を通知する（ステップＳ１３０６）。さらに、ＯＳは、他のプロセッサに対象となるＣＰＵの停止を通知し（ステップＳ１３０７）、電源機構を操作して（ステップＳ１３０８）、対象となるＣＰＵへの電力供給を完全に停止させ、一連の処理を終了する。

一方、ステップＳ１３０１において、ＣＰＵ数が規定値以下であると判断された場合（ステップＳ１３０１：Ｙｅｓ）、ＯＳは、レジスタの内容を共有メモリ１０４に待避し（ステップＳ１３０９）、ローカルメモリの内容を共有メモリ１０４に待避する（ステップＳ１３１０）。その後、ＯＳは、キャッシュをフラッシュし（ステップＳ１３１１）、ス
テップＳ１３０７の処理に移行する。

図１４は、電源停止時のＲＡＩＤコントローラによる動作手順を示すフローチャートである。図１４のフローチャートは、電源停止時にＲＡＩＤコントローラ８０１内の各機能部がどのような処理を行うかを表している。

図１４において、ＲＡＩＤコントローラ８０１は、コマンド受信部９０４が電源停止コマンドの受信をトリガに動作を開始する。まず、コマンド受信部９０４は、停止後のＣＰＵ数が規定値以下か否かを判断する（ステップＳ１４０１）。ステップＳ１４０１において、ＣＰＵ数が規定値以下ではないと判断された場合（ステップＳ１４０１：Ｎｏ）、コマンド受信部９０４は、停止したＣＰＵのローカルメモリの内容の待避を開始して（ステ
ップＳ１４０２）、パリティデータの再構築を開始する（ステップＳ１４０３）。

ステップＳ１４０２によってローカルメモリの内容の待避が開始されると、データ待避部９０６は、未待避のデータを検索する（ステップＳ１４１１）。復元データ生成部９０５は、ステップＳ１４１１の検索結果を利用して、対応するデータを読み込み（ステップＳ１４２１）、復元データを生成する（ステップＳ１４２２）。復元データ生成部９０５によって復元データが生成されると、データ待避部９０６は、共有メモリ１０４に復元データを待避する（ステップＳ１４１２）。データ待避部９０６による待避処理は、未待避のデータがなくなるまで繰り返し行われる。

一方、ステップＳ１４０１において、ＣＰＵ数が規定値以下であると判断された場合（ステップＳ１４０１：Ｙｅｓ）、ステップＳ１４０２と同様に停止したＣＰＵのローカルメモリの内容の待避を開始する（ステップＳ１４０４）。ステップＳ１４０４の場合は、ステップＳ１４０２とは異なり、従来の待避処理を行う。すなわち、ステップＳ１４０４の待避処理が完了するまで、ローカルメモリへの電力供給が継続される。

一方、ステップＳ１４０２の待避処理が開始された場合、ステップＳ１４０３の処理後に、パリティ再構築部９０３によって未再構成データを検索する（ステップＳ１４３１）。その後、パリティ生成部９０２によって、対応するデータを読み込み（ステップＳ１４４１）、パリティデータを生成する（ステップＳ１４４２）。その後、パリティ生成部９０２によって、生成されたパリティデータを各ローカルメモリへ書き込む（ステップＳ１４４３）。上述したパリティデータの生成は、未再構成データがなくなるまで、繰り返し行われる。

図１５〜１８は、ＣＰＵ＃１の停止動作の手順を示す説明図である。図１５では、ローカルメモリ１が停止された状態を表している。ローカルメモリ１の停止に伴い、ローカルメモリ１に格納されたデータを復元しなければならない。また、同時に、稼働中のローカルメモリが停止されても格納されていたデータを復元可能にするため、パリティデータを再構築しなければならない。

復元データ生成部９０５では、ＤＡＴＡ１１，３１およびＰａｒｉｔｙ１１，２１，３１によってＤＡＴＡ２１が復元される。復元されたデータはデータ待避部９０６によって共有メモリ１０４に格納される。また、パリティ生成部９０２では、稼働中のローカルメモリに格納されているデータを復元するパリティデータ（Ｐａｒｉｔｙ１１，３１）を生成する。生成されたパリティデータは、パリティ再構築部９０３によってローカルメモリ３に格納される。

引き続き、図１６のように、復元データ生成部９０５では、ＤＡＴＡ１２，４１およびＰａｒｉｔｙ４１，１２，２２によってＤＡＴＡ２２が復元される。復元されたデータはデータ待避部９０６によって共有メモリ１０４に格納される。また、パリティ生成部９０２では、稼働中のローカルメモリに格納されているデータを復元するパリティデータ（Ｐａｒｉｔｙ４１，１２）を生成する。生成されたパリティデータは、パリティ再構築部９０３によってローカルメモリ２に格納される。

引き続き、図１７のように、復元データ生成部９０５では、ＤＡＴＡ３２，４３およびＰａｒｉｔｙ２３，３３，４３によってＤＡＴＡ２３が復元される。復元されたデータはデータ待避部９０６によって共有メモリ１０４に格納される。また、パリティ生成部９０２では、稼働中のローカルメモリに格納されているデータを復元するパリティデータ（Ｐａｒｉｔｙ３２，４２）を生成する。生成されたパリティデータは、パリティ再構築部９０３によってローカルメモリ０に格納される。

最後に、図１８のように、停止されたローカルメモリに格納されたＤＡＴＡ２Ｎまでの処理が終了すると、復元データ生成部９０５の処理は終了し、パリティ生成部９０２では、稼働中のローカルメモリに格納されているデータを復元するパリティデータ（Ｐａｒｉｔｙ３Ｎ，４Ｎ）を生成する。生成されたパリティデータは、パリティ再構築部９０３によってローカルメモリ０に格納される。

上述の図１３〜１８にて説明したように、電源停止時にはＯＳからＲＡＩＤコントローラ８０１へ電力供給の停止に関する指示が入力される。ＲＡＩＤコントローラ８０１は、コマンド受信部９０４によってＯＳからの指示に応答してデータの復元やパリティデータの再構築を行う。したがって、ローカルメモリ内のデータの待避を待たずに済むため、高速な電源停止が可能となる。

＜電源停止中のアクセス＞
図１９は、電源停止中のローカルメモリへのアクセス例を示す説明図である。マルチコアプロセッサ８００によって実行する処理の内容によっては図１９のように電源停止中のローカルメモリに対するアクセスが発生することがある。アクセスとは、データの読込を行う読込処理と、データの書込を行う書込処理とを意味する。

読込処理、書込処理いずれの場合も実際のアクセス先であるローカルメモリ１は停止中であり、対象となるデータは存在しない。そこで、ＲＡＩＤコントローラ８０１は、ＣＰＵ＃０からのアクセスを検出して、ＣＰＵ＃０の要求をローカルメモリ１の代わりに受け持って、実際に対象となるデータが存在するメモリ（たとえば共有メモリ１０４）へ誘導する。

図２０は、電源停止中のＲＡＩＤコントローラによるアクセス手順を示すフローチャートである。図２０のフローチャートは、停止中のローカルメモリへのアクセスが発生した際のアクセス内容に応じたＲＡＩＤコントローラ８０１の動作の違いを表している。

図２０において、メモリアクセス監視部９０１は、停止中のローカルメモリへのアクセスの検出をトリガにして処理を開始する。メモリアクセス監視部９０１は、まず、検出したアクセスが読込処理か否かを判断する（ステップＳ２００１）。ステップＳ２００１において、検出したアクセスが読込処理であると判断された場合（ステップＳ２００１：Ｙｅｓ）、メモリアクセス監視部９０１は、アクセス先のデータが再構成済みか否かを判断する（ステップＳ２００２）。

ステップＳ２００２において、再構成済みのデータでないと判断された場合（ステップＳ２００２：Ｎｏ）、メモリアクセス監視部９０１は、現状ではアクセス対象となるデータが存在しないため、パリティデータからローカルメモリに格納されていたデータを復元する（ステップＳ２００３）。一方、ステップＳ２００３において、再構成済みのデータであると判断された場合（ステップＳ２００２：Ｙｅｓ）、対象となるデータは共有メモリ１０４に復元済みであることを意味する。したがって、メモリアクセス監視部９０１は、共有メモリ１０４に待避したデータを読み込む（ステップＳ２００４）。

ステップＳ２００１によってアクセスが読込処理と判断された場合には、ステップＳ２００３もしくはＳ２００４の処理によって対象となるデータが読み込まれる。したがって、メモリアクセス監視部９０１は、読込元ＣＰＵにデータを返して（ステップＳ２００５）、一連の処理を終了する。

なお、ステップＳ２００１において、読込処理ではないと判断された場合（ステップＳ２００１：Ｎｏ）、メモリアクセス監視部９０１は、今回検出したアクセスは書込処理であると判断する。したがって、メモリアクセス監視部９０１は、共有メモリ１０４の待避領域へ対象となるデータを書き込んで（ステップＳ２００６）、一連の処理を終了する。アクセスが書込処理であった場合には、今回のアクセスによってデータ自体が更新されてしまう。したがって、読込処理のようにローカルメモリに格納されていたデータを復元する必要はない。

また、上述したように、今回検出されたアクセスが読込処理であり、対象となるデータが再構成されていなかった場合には、ステップＳ２００３によってデータが復元されている。ステップＳ２００３において、データを復元する際の処理の主体は復元データ生成部９０５となる。

具体的に説明すると、復元データ生成部９０５は、ステップＳ２００３の処理がトリガとなり、一連の処理を開始する。復元データ生成部９０５は、まず、対応するデータ（パリティデータ）を読み込み（ステップＳ２０１１）、読み込んだデータを利用して、ローカルメモリに格納されていたデータを復元データとして生成する（ステップＳ２０１２）。ステップＳ２０１２によって生成されたデータは、メモリアクセス監視部９０１に返され、ステップＳ２００５の処理に利用される。以下に、停止中のローカルメモリへの読込処理と書込処理との手順について具体例を挙げて説明する。

図２１，２２は、電源停止中のローカルメモリへの読込手順を示す説明図である。図２１では、ＣＰＵ＃０から停止中のＣＰＵ＃１のローカルメモリ１へ読込処理の要求が発生している。ＣＰＵ＃０は、ローカルメモリ１に格納されている（実際には格納されていた）データを順に読み出すため、まず、先頭のＤＡＴＡ２１を読込処理の対象のデータとしている。

メモリアクセス監視部９０１は、ＣＰＵ＃０からの読込処理を検出すると、ＤＡＴＡ２１が共有メモリ１０４に再構成済みのデータか否かを判断する。図２１の例では、ローカルメモリ１のＤＡＴＡ２１〜２３までが共有メモリ１０４に再構成済みのデータである。したがって、メモリアクセス監視部９０１は、ＣＰＵ＃０に共有メモリ１０４に格納されているＤＡＴＡ２１を読み込ませる。

ＣＰＵ＃０は、ローカルメモリ１に格納されていたデータをＤＡＴＡ２１から順番に読み込んでいくが、図２２に例示したように、対象データがＤＡＴＡ２４以降となると共有メモリ１０４から読み込むことができない。そこで、ＲＡＩＤコントローラ８０１は、復元データ生成部９０５によって、再構成が済んでいないデータを復元する。

たとえば、図２２のように、ＤＡＴＡ２４を復元するには、復元データ生成部９０５は、稼働中のＣＰＵ＃０，２，３のローカルメモリ０，２，３に格納されているＤＡＴＡ１４，３４およびＰａｒｉｔｙ１４，２４，３４の排他的論理和演算を満たすデータを生成することによって、ＤＡＴＡ２４を得ることができる。ＤＡＴＡ２５以降についても同様の手順で復元することができる。メモリアクセス監視部９０１は、復元データ生成部９０５によって復元されたデータをＣＰＵ＃０に読み込ませることによって、停止中のローカルメモリ１であっても稼働中と遜色なくデータを読み込むことができる。

図２３，２４は、電源停止中のローカルメモリへの書込手順を示す説明図である。図２３では、ＣＰＵ＃０から停止中のＣＰＵ＃１のローカルメモリ１への書込処理の要求が発生している。ＣＰＵ＃０は、ローカルメモリ１に格納されている（実際には格納されていた）データの中のアドレス順に順次書き込むため、まず、先頭のＤＡＴＡ２１を書込処理の対象のデータとしている。

メモリアクセス監視部９０１は、ＣＰＵ＃０からの書込処理を検出すると、共有メモリ１０４にＤＡＴＡ２１を書き込ませる。その後、図２４ように対象となるデータがＤＡＴＡ２４に移行しても、メモリアクセス監視部９０１は、図２３の処理と同様に共有メモリ１０４にＤＡＴＡ２４を書き込ませる。

読込処理とは異なり、書込処理の際には、書込後のデータが最新のデータとなるため、共有メモリ１０４に対象となるデータが再構成済みか否かを判断する必要はない。いずれのデータであっても、メモリアクセス監視部９０１は、ＣＰＵ＃０に対して一様に共有メモリ１０４に書き込むように誘導すればよい。

以上説明したように、停止中のローカルメモリへのアクセスが発生した場合には、アクセスが、読込処理であるのか書込処理であるのかに応じてＲＡＩＤコントローラ８０１の処理内容が異なる。読込処理であった場合には、さらに、読込処理の対象となるデータが再構成済みのデータであれば単純に共有メモリ１０４から読み込むように誘導すればよいが、再構成済みのデータではない場合には、逐一復元データを生成して、アクセス元のＣＰＵに読み込ませる必要がある。

しかしながら、読込処理が完了した後は、データ自体に変更はないためそのまま一連の処理を終わらせることができる。また、書込処理によってデータ自体の変更があった場合でも、稼働中のＣＰＵのローカルメモリには影響しないためパリティデータを再構築する必要はない。

＜電源復帰時の動作＞
図２５は、電源復帰時の動作例を示す説明図である。次に、一旦、電源停止されたＣＰＵに再度電力が供給される電源復帰時の動作について説明する。図２５のように、ＣＰＵ＃１およびローカルメモリ１の電力供給が再開すると、ＲＡＩＤコントローラ８０１は、まず、共有メモリ１０４に待避されていたデータを、ローカルメモリ１に復元する（ステップＳ２５０１）。

続いて、ＲＡＩＤコントローラ８０１は、電源復帰後の稼働中のＣＰＵの数に応じてパリティデータを再構築する（ステップＳ２５０２）。ＣＰＵ＃１が復帰したことによって、ＣＰＵ＃０〜３が稼働中となった。したがって、各ＣＰＵのローカルメモリは、自ローカルメモリに格納しているデータを復元するためのパリティデータを、自ローカルメモリ以外の３つのローカルメモリのパリティ領域に格納する。

図２６は、実施例１における電源復帰時のＯＳの動作手順を示すフローチャートである。図２６のフローチャートは、停止中のＣＰＵが他のＣＰＵからの復帰指示を受けて、通常動作の処理を再開するまでの手順を示している。

図２６において、ＯＳは、停止中のＣＰＵ以外の他のＣＰＵにおける電源復帰の決定処理をトリガに動作を開始する。まずＯＳは、上述の他のＣＰＵから停止中のＣＰＵの電源機構を操作させる（ステップＳ２６０１）。

その後、ＯＳは、電源復帰の対象ＣＰＵにおいて、ＲＡＤＩコントローラ８０１に復帰を通知する（ステップＳ２６１１）。続いて、ＯＳは、レジスタの内容を復元し（ステップＳ２６１２）、他のプロセッサ（他のＣＰＵ）に復帰を通知する（ステップＳ２６１３）。その後、ＯＳは、復帰させたＣＰＵの処理を再開させることによって（ステップＳ２６１４）、一連の復帰処理を終了する。

図２７は、電源復帰時のＲＡＩＤコントローラによる動作手順を示すフローチャートである。図２７のフローチャートは、ＯＳから電源復帰指示を受けた際のＲＡＩＤコントローラ８０１の動作を表している。

図２７において、ＲＡＩＤコントローラ８０１は、コマンド受信部９０４において、ＯＳから出力された電源復帰に関するコマンドの受信をトリガに処理を開始する。まず、コマンド受信部９０４は、復帰処理の対象となるデータが再構成中か否かを判断する（ステップＳ２７０１）。なお、対象となるデータとはＯＳから復帰指示がなされたＣＰＵがアクセスするローカルメモリに格納されていたデータを意味する。

ステップＳ２７０１において、再構成中であると判断された場合（ステップＳ２７０１：Ｙｅｓ）、ローカルメモリの復元とパリティデータの再構築を開始する（ステップＳ２７０２）。一方、再構成中でないと判断された場合も（ステップＳ２７０１：Ｎｏ）、同様に、ローカルメモリの復元とパリティデータの再構築を開始する（ステップＳ２７０４）。後述するように、ステップＳ２７０２の場合は、再構成中のデータについては、パリティデータを利用して復元してから、データ待避部９０６の処理に移行する。一方、ステップＳ２７０４の場合には、再構成中のデータを扱う必要がないため、そのままデータ待避部９０６の処理に移行する。

ステップＳ２７０２の処理の後、コマンド受信部９０４は、ローカルメモリに格納されていたデータの復元を開始し（ステップＳ２７０３）、復元データ生成部９０５によって復元データの生成を実行させる。

復元データ生成部９０５では、まず、未再構築のパリティデータを検索し（ステップＳ２７４１）、対応するデータを読み込む（ステップＳ２７０２）。その後、復元データ生成部９０５は、ステップＳ２７４２において読み込んだデータを用いて復元データを生成する（ステップＳ２７４３）。ステップＳ２７４３による復元データの生成は未再構築のパリティデータがなくなるまで繰り返して実行される。

コマンド受信部９０４の処理に戻り、ステップＳ２７０１において再構成中ではないと判断された場合（ステップＳ２７０１：Ｎｏ）、コマンド受信部９０４は、ローカルメモリに格納されていたデータの復元を開始する（ステップＳ２７０４）。上述したように、ステップＳ２７０４の場合、ステップＳ２７００２の処理と異なり、再構成中のデータは存在しないため、復元データ生成部９０５による復元データの生成は行われない。

また、コマンド受信部９０４は、ステップＳ２７０２およびＳ２７０４が開始されると、パリティ再構築部９０３によって未再構成データの検索が行われる（ステップＳ２７１１）。ステップＳ２７１１における未再構成データとは、各ローカルメモリに格納されているデータの中の、電源復帰後に稼働中のＣＰＵ数に応じたパリティデータの再構築が済んでいないデータを意味する。

続いて、パリティ生成部９０２によって、パリティ再構築部９０３によって検索された未再構成データを対象としたパリティデータの生成が行われる。まず、パリティ生成部９０２は、対応するデータを読み込み（ステップＳ２７２１）、対応するデータを復元するためのパリティデータを生成する（ステップＳ２７２２）。その後。パリティ生成部９０２は、生成したパリティデータを、各ＣＰＵのローカルメモリに書き込んで（ステップＳ２７２３）、一連の処理を終了する。

また、データ待避部９０６では、コマンド受信部９０４のステップＳ２７０２もしくはＳ２７０４の処理の後、データ待避処理が開始される。データ待避部９０６は、まず、ローカルメモリに未復旧のデータを検索する（ステップＳ２７３１）。その後、ステップＳ２７３１によって検索されたデータをローカルメモリへ復旧する（ステップＳ２７３２）。上述したデータ待機処理は、未復旧のデータがなくなるまで繰り返し行われる。

図２８，２９は、ＣＰＵ＃１の復帰動作の手順を示す説明図である。図２８では、停止中であったＣＰＵ＃１の復帰指示が行われ、ＣＰＵ＃１およびローカルメモリ１への電力供給が開始されている。ローカルメモリ１に格納されていたデータは電源停止時に一旦すべて消失している。そこで、ＲＡＩＤコントローラ８０１は、ローカルメモリ１が復帰状態になると、共有メモリ１０４に待避されていたデータを順次、ローカルメモリ内に復元する。

具体的には、図２８のようにＲＡＩＤコントローラ８０１は、まず、データ待避部９０６によって、共有メモリ１０４からＤＡＴＡ２１を読み込み、ローカルメモリ１内に復帰する。その後、パリティデータ生成部９０２は、現在各ローカルメモリに格納されているデータを復元するための、パリティデータを生成する。

図２８の例では、パリティ生成部９０２は、ローカルメモリ０に格納されているＤＡＴＡ１１と、ローカルメモリ１に格納されているＤＡＴＡ２１とローカルメモリ２に格納されているＤＡＴＡ３１を利用してＰａｒｉｔｙ１１，２１，３１を生成する。生成されたパリティデータ（Ｐａｒｉｔｙ１１，２１，３１）は、パリティ再構築部９０３によって、現在ローカルメモリ３の中のパリティデータ（Ｐａｒｉｔｙ１１，３１）が格納されている位置に上書きされる。

ＲＡＩＤコントローラ８０１は、ＤＡＴＡ１１以降のデータについても同様に共有メモリ１０４から読み出してローカルメモリ１に格納する。その後、未再構成のデータを処理する場合がある。ここで未再構成とは、電源停止後に、パリティデータによって共有メモリ１０４に復元データが生成されていないデータを意味する。本来、停止されたローカルメモリに格納されていたデータは、パリティデータによって共有メモリ１０４に再構成される。ところが、電源停止から復帰までの期間が短い場合にはすべてのデータが共有メモリ１０４に再構成される前の状態で復帰処理が始まってしまうこともある。

図２９では、ＤＡＴＡ２４が共有メモリ１０４内に再構成されていない場合を表している。このような再構成されていないデータの場合、単純に共有メモリ１０４から読み込んでローカルメモリ１に復帰させることはできない。そこで、復元データ生成部９０５によって、パリティデータからＤＡＴＡ２４が生成される。

ＤＡＴＡ２４は、具体的には、ローカルメモリ０に格納されたＤＡＴＡ１４と、ローカルメモリ２に格納されたＤＡＴＡ３４と、ローカルメモリ３に格納されたＰａｒｉｔｙ１４，２４，３４との排他的論理和演算を行うことによって得られる。図２８のように、ＣＰＵの電源が停止された後に再構築されたパリティデータは、図２８のローカルメモリ３に格納されていたＰａｒｉｔｙ１１，３１と自ローカルメモリ以外の２つのＤＡＴＡに基づいて対象となるデータが復元されている。

したがって、Ｐａｒｉｔｙ１４，２４，３４など、３つのローカルメモリに格納されているデータによって復元されるようなパリティデータが格納されていることは、すなわち、ＤＡＴＡ２４以降のデータのように、停止後のパリティデータの再構築の済んでいないデータがあることを意味している。

上述の図２５〜２９にて説明したように、電源停止時にはＯＳからＲＡＩＤコントローラ８０１へ電力供給の再開に関する指示が入力される。ＲＡＩＤコントローラ８０１は、コマンド受信部９０４によってＯＳからの指示に応答してデータの復元やパリティデータの再構築を行う。ＲＡＩＤコントローラ８０１は、電源停止中に他のＣＰＵから停止中のローカルメモリへのアクセスが発生し、データの内容が更新されるような場合であっても、共有メモリ１０４に復元したデータに対して書込処理を施すように誘導している（詳しくは上記＜停止中のアクセス＞参照）。したがって、共有メモリ１０４に待避されているデータをローカルメモリに復帰させるだけで、ローカルメモリは、即座に最新の更新内容が反映されたデータが格納されたことになる。

＜電源復帰中のアクセス＞
図３０は、復元中のローカルメモリへのアクセス例を示す説明図である。マルチコアプロセッサ８００によって実行する処理の内容やタイミングによっては、図３０のように復帰中のローカルメモリに対するアクセスが発生することがある。復帰処理によって既にローカルメモリ内に復帰したデータに対するアクセスの場合には問題がない。

ところが、図３０のように、ローカルメモリ内に復帰していないデータに対するアクセスの場合には、対象となるデータは存在しない。そこで、ＲＡＩＤコントローラ８０１は、ＣＰＵ＃０からのアクセスを検出して、ＣＰＵ＃０の要求をローカルメモリ１の代わりに受け持って、実際に対象となるデータを復元してアクセス可能にする。

図３１は、復元中のＲＡＩＤコントローラによるアクセス手順を示すフローチャートである。図３１のフローチャートは、復元中のローカルメモリへのアクセスが発生した際のアクセス内容に応じたＲＡＩＤコントローラ８０１の動作の違いを表している。

図３１において、メモリアクセス監視部９０１は、復元中のローカルメモリへのアクセスの検出をトリガにして処理を開始する。メモリアクセス監視部９０１は、まず、検出したアクセスが読込処理か否かを判断する（ステップＳ３１０１）。ステップＳ３１０１において、検出したアクセスが読込処理であると判断された場合（ステップＳ３１０１：Ｙｅｓ）、メモリアクセス監視部９０１は、アクセス先のデータが再構成済みか否かを判断する（ステップＳ３１０２）。

ステップＳ３１０２において、再構成済みのデータでないと判断された場合（ステップＳ３１０２：Ｎｏ）、メモリアクセス監視部９０１は、現状ではアクセス対象となるデータが存在しないため、パリティデータからローカルメモリに格納されていたデータを復元する（ステップＳ３１０３）。一方、ステップＳ３１０２において、再構成済みのデータであると判断された場合（ステップＳ３１０２：Ｙｅｓ）、対象となるデータは共有メモリ１０４に復元済みであることを意味する。したがって、メモリアクセス監視部９０１は、共有メモリ１０４に待避したデータを読み込む（ステップＳ３１０４）。

ステップＳ３１０１によってアクセスが読込処理と判断された場合には、ステップＳ３１０３もしくはＳ３１０４の処理によって対象となるデータが読み込まれる。したがって、メモリアクセス監視部９０１は、読込元ＣＰＵにデータを返して（ステップＳ３１０５）、一連の処理を終了する。

なお、ステップＳ３１０１において、読込処理ではないと判断された場合（ステップＳ３１０１：Ｎｏ）、メモリアクセス監視部９０１は、今回検出したアクセスは書込処理であると判断する。したがって、メモリアクセス監視部９０１は、対象となるローカルメモリへ書き込んで（ステップＳ３１０６）、一連の処理を終了する。その後、ステップＳ３１０６によって書き込まれたデータが最新のデータとなるため、メモリアクセス監視部９０１は、最新のデータを復元するためのパリティデータを生成して現在のパリティデータに対して更新を行う（ステップＳ３１０７）。

ステップＳ３１０７によってパリティデータの更新の指示がなされると、パリティ生成部９０２では、上述したように最新のデータを復元するためのパリティデータを生成する。パリティ生成部９０２は、まず、対象となるデータの読込を行う（ステップＳ３１２１）。

続いてパリティ生成部９０２は、ステップＳ３１２１において読み込まれたデータを用いてパリティデータを生成する（ステップＳ３１２２）。最後に、パリティ生成部９０２は、対応するパリティデータを、ステップＳ３１２２にて生成されたパリティデータに更新して（ステップＳ３１２３）、一連の処理を終了する。

また、上述したように、今回検出されたアクセスが読込処理であり、対象となるデータが再構成されていなかった場合には、ステップＳ３１０３によってデータが復元されている。ステップＳ３１０３において、データを復元する際の処理の主体は復元データ生成部９０５となる。

具体的に説明すると、復元データ生成部９０５は、ステップＳ３１０３の処理がトリガとなり、一連の処理を開始する。復元データ生成部９０５は、まず、対応するデータ（パリティデータ）を読み込み（ステップＳ３１１１）、読み込んだデータを利用して、ローカルメモリに格納されていたデータを復元データとして生成する（ステップＳ３１１２）。

ステップＳ３１１２によって生成されたデータは、メモリアクセス監視部９０１に返され、ステップＳ３１０５の処理に利用される。以下に、復元中のローカルメモリへの読込処理と書込処理との手順について具体例を挙げて説明する。

図３２〜３４は、復元中のＣＰＵ＃１への読込動作の手順を示す説明図である。図３２では、ＣＰＵ＃０からＣＰＵ＃１がアクセスするローカルメモリ１に格納されている各データに対する読込動作が発生している。図３２のように、ローカルメモリ１には、ＤＡＴＡ２１，２２のデータが復元済みである。したがって、ＣＰＵ＃０は、ＤＡＴＡ２１を読み込む際には、ローカルメモリ１を参照する。このときＲＡＩＤコントローラ８０１のメモリアクセス監視部９０１は、ＣＰＵ＃０による読込動作の発生を検出する。

図３３に示すように、ＣＰＵ＃０が、ＤＡＴＡ２３を読み込む場合、メモリアクセス監視部９０１は、ＣＰＵ＃０に通知して、データ待避部９０６によって、共有メモリ１０４に復帰されたＤＡＴＡ２３を読み込ませる。

さらに、図３４に示すように、ローカルメモリ１にも共有メモリ１０４にも復元されていないＤＡＴＡ２４を読み込む場合、ＲＡＩＤコントローラ８０１は、まず、メモリアクセス監視部９０１によって、復元中のデータへのアクセスであることを検出する。

復元データ生成部９０５では、ローカルメモリ１以外の稼働中のローカルメモリ（ローカルメモリ０，２，３）に格納されているＤＡＴＡ１３，ＤＡＴＡ３３およびＰａｒｉｔｙ１４，２４，３４によってＤＡＴＡ２４を復元する。復元されたデータは、ローカルメモリ１に格納され、ＣＰＵ＃０によって読み込まれる。

図３５，３６は、復元中のＣＰＵ＃１への書込動作の手順を示す説明図である。図３５では、ＣＰＵ＃０からＣＰＵ＃１がアクセスするローカルメモリ１に格納されている各データに対する書込動作が発生している。図３５のように、ローカルメモリ１には、ＤＡＴＡ２１，２２のデータが復元済みである。したがって、ＣＰＵ＃０は、ＤＡＴＡ２１への書込を行う際には、ローカルメモリ１にそのままアクセスする。このときＲＡＩＤコントローラ８０１のメモリアクセス監視部９０１は、ＣＰＵ＃０による書込動作の発生を検出する。

また、図３５のように、ＤＡＴＡ２１の内容が更新されると、パリティ生成部９０２は、更新後のデータを復元できるように、新たなパリティデータを生成し、現在のパリティデータに上書きする。

その後、図３６のように、ローカルメモリ１内に復元されていないＤＡＴＡ２４への書込処理が発生した場合には、ＣＰＵ＃０は、そのままローカルメモリ１への書込処理を行う。読込処理と異なり、書込処理の場合には、データの内容が上書きされるため、ＤＡＴＡ２４を復元する必要がない。なお、新たにＤＡＴＡ２４が書き込まれた場合、パリティ生成部９０２は、更新後のデータを復元できるように、新たなパリティデータを生成し、現在のパリティデータに上書きする。

以上説明したように、復元中のローカルメモリへのアクセスが発生した場合には、読込処理であるのか書込処理であるのかに応じてＲＡＩＤコントローラ８０１の処理内容が異なる。読込処理であった場合には、さらに、読込処理の対象となるデータが再構成済みのデータであれば単純に共有メモリ１０４から読み込むように誘導すればよいが、再構成済みのデータではない場合には、逐一復元データを生成して、アクセス元のＣＰＵに読み込ませる必要がある。

しかしながら、読込処理が完了した後は、データ自体に変更はないためそのまま一連の処理を終わらせることができる。また、書込処理によってデータ自体の変更があった場合には、書込処理を反映させた最新のパリティデータを生成して稼働中のＣＰＵのローカルメモリへ格納することによって、また、急にＣＰＵの電源停止が起こっても、高速に最新のデータを復元することができる。

以上説明したように、実施例１では、ＣＰＵへの電源停止に伴ってローカルメモリへの電力供給が停止して消費電力を削減する構成になっている。通常、揮発性メモリであるローカルメモリへの電力の供給が停止すると、格納されていたデータは消失してしまい、復元することはできない。ところが、実施例１のデータ復元装置１１０は、あらかじめ、各ローカルメモリに格納されているデータを復元するためのパリティデータを、稼働中のローカルメモリにそれぞれ格納する。したがって、もしＣＰＵ１が電源停止となり、ローカルメモリ１への電力の供給が急に途絶えたとしても、ローカルメモリ１に格納されているデータ自体は消失してしまうが、即座に格納されていたデータを復元することができる。

また、マルチコアプロセッサ８００では、不必要なＣＰＵを停止させて、電力効率を上げるために、各ＣＰＵに対する電源停止や電源復帰が頻繁に発生するような利用形態が想定される。したがって、パリティデータによるデータの復元やパリティデータの再構築が完全に完了する前にもかかわらず、データの復元が不完全な状態のローカルメモリへアクセスが発生することもある。

そこで、実施例１では、ＲＡＩＤコントローラ８０１によって、対象となるデータが現在どのような状態であるかを管理している。したがって、ＣＰＵによるアクセスエラーやデータの更新漏れのない、適切かつ効率的なアクセスを支援することができる。

（実施例２）
図３７は、アクセス監視バスを備えたマルチコアプロセッサの構成例を示す説明図である。実施例２および後述する実施例３は、実施例１とは異なり、ローカルメモリバス１０２の備わっていないマルチコアプロセッサ３７００を利用する場合について説明する。マルチコアプロセッサによっては設計や構造の制約上、実施例１のようなローカルメモリバス１０２を備えていないものもある。実施例２，３では、上述のようにローカルメモリなバス１０２が備えられていないマルチコアプロセッサを対象としたデータ復元処理の実施例について説明する。

ローカルメモリバス１０２が備わっていないとは、ローカルメモリ同士が相互にアクセスできないということを意味する。すなわち、各ＣＰＵは、自ＣＰＵ以外の他のＣＰＵがどのようなアクセスを行っているかを把握することができない。

そこで、実施例２のマルチコアプロセッサ３７００の場合、新たにアクセス監視バス３７０１を追加した構成にすることによって、ＲＡＩＤコントローラ３８００による各ローカルメモリへのアクセスの監視や、パリティデータの更新およびローカルメモリ電源停止時のデータ待避を可能にする。

図３８は、実施例２におけるＲＡＩＤコントローラの内部構成を示すブロック図である。図３８のように、ＲＡＩＤコントローラ３８００は、実施例１と同様に、ローカルメモリの更新を監視するメモリアクセス監視部９０１と、パリティデータを生成するパリティ生成部９０２と、パリティデータの再構築を行うパリティ再構築部９０３と、ＣＰＵからの電源停止のコマンドを受信するコマンド受信部９０４と、パリティデータからローカルメモリに格納されていたデータを復元する復元データ生成部９０５と、電源停止時にローカルメモリの内容を待避するデータ待避部９０６と、を備えている。

加えて、実施例２のＲＡＩＤコントローラ３８００は、電源再開時にローカルメモリの内容を復元するデータ復帰部９０７と、ローカルメモリの稼働状態を記録するローカルメモリ稼働情報テーブル３８０１とを備えている。ローカルメモリ稼働情報テーブル３８０１は、ＣＰＵ＃０〜３の稼働状況を管理するデータテーブルである。したがって、対応するＣＰＵの稼働状況に応じて、「稼働」もしくは「停止」のいずれかの情報が設定されている。

＜電源停止時の動作＞
図３９は、実施例２における電源停止時のＯＳの動作手順を示すフローチャートである。図３９のフローチャートは、マルチコアプロセッサ３７００内のいずれかのＣＰＵの電源停止時にＯＳからＲＡＩＤコントローラ３８００へ出力される指示内容と、その手順を表している。

図３９において、ＯＳは電源停止の決定をトリガに動作を開始する。まず、ＯＳは、現在のＣＰＵ数が規定値以下か否かを判断する（ステップＳ３９０１）。ステップＳ３９０１において、ＣＰＵ数が規定値以下ではないと判断された場合（ステップＳ３９０１：Ｎｏ）、ＯＳは、パリティが再構成中か否かを判断する（ステップＳ３９０２）。

ステップＳ３９０２において、パリティが再構成中であると判断された場合（ステップＳ３９０２：Ｙｅｓ）、ＯＳは、再構成が完了するまで待ち（ステップＳ３９０３）、レジスタの内容を共有メモリ１０４に待避させる（ステップＳ３９０４）。なお、ステップＳ３９０２において、パリティが再構成中ではないと判断された場合（ステップＳ３９０
２：Ｎｏ）、ステップＳ３９０３によって待機することなく、ステップＳ３９０４の処理に移行する。

その後、ＯＳは、キャッシュをフラッシュして（ステップＳ３９０５）、ＲＡＩＤコントローラ３８００に対象となるＣＰＵの停止を通知する（ステップＳ３９０６）。さらに、ＯＳは、他のプロセッサに対象となるＣＰＵの停止を通知し（ステップＳ３９０７）、電源機構を操作して（ステップＳ３９０８）、対象となるＣＰＵへの電力供給を完全に停
止させ、一連の処理を終了する。

一方、ステップＳ３９０１において、ＣＰＵ数が規定値以下と判断された場合（ステップＳ３９０１：Ｙｅｓ）、ＯＳは、レジスタの内容をメモリに待避し（ステップＳ３９０９）、ローカルメモリの内容をメモリに待避する（ステップＳ３９１０）。その後、ＯＳは、キャッシュをフラッシュし（ステップＳ３９１１）、ステップＳ３９０７の処理に移
行する。

以上説明したように、マルチコアプロセッサ３７００のＣＰＵを停止させて、稼働中のローカルメモリのいずれかへの電力の供給を停止する場合は、まず、ＯＳなどの上位プログラムによって、従来通りレジスタの待避とキャッシュのフラッシュを行う。その後、ＯＳは、ローカルメモリの内容は待避せずにＲＡＩＤコントローラ３８００に自ＣＰＵの停止を通知してから電源を切る。

なお、電源を切る際に、直前に別のＣＰＵの電源が停止されており、パリティデータが再構築中の場合は、ＲＡＩＤコントローラ３８００に現在の状態を問い合わせる。そして、再構築が終了するまで待ってから自ＣＰＵの電源を切る。また、実施例１でも説明したが、停止するＣＰＵ数が増えるとローカルメモリ一つあたりのパリティデータに必要な領域が（データ領域サイズ／稼働数）と増えてしまう。

したがって、あらかじめ用意されたパリティデータ領域に収まらなくなった場合に備えて、現在の稼働ローカルメモリ数が規定値以下の場合は、ＲＡＩＤコントローラ３８００は利用せず、従来通り、ローカルメモリに格納されているデータを共有メモリ１０４に待避してから電源を停止する処理を採用する。以下には、上述した電源停止時に各機能部の処理内容について、それぞれ説明する。

図４０は、コマンド受信部の動作手順を示すフローチャートである。図４０のフローチャートは、電源停止時にコマンド受信部９０４によって実行される処理内容を表している。図４０に示しているように、電源停止はＯＳからＣＰＵへの電源停止コマンドによってその処理が実行される。したがって、ＲＡＩＤコントローラ３８００では、コマンド受信部９０４によるコマンド受信によって一連の動作が開始される。

図４０において、コマンド受信部９０４は、なんらかのコマンド受信をトリガに動作を開始する。まず、コマンド受信部９０４は、受信コマンドを解析する（ステップＳ４００１）。ステップＳ４００１の解析の結果、コマンドが電源停止の指示だった場合（ステップＳ４００１：電源停止）、コマンド受信部９０４は、ローカルメモリ稼働情報テーブル３８０１を待避中に更新する（ステップＳ４００２）。さらに、コマンド受信部９０４は、データ待避部９０６に対して、停止したローカルメモリを通知して（ステップＳ４００３）、一連の処理を終了する。

一方、ステップＳ４００１の解析の結果、コマンドが電源復帰の指示だった場合（ステップＳ４００１：電源復帰）、コマンド受信部９０４は、ローカルメモリ稼働情報テーブル３８０１を停止中に更新する（ステップＳ４００４）。さらに、コマンド受信部９０４は、データ復帰部９０７に対して復帰したローカルメモリを通知して（ステップＳ４００５）、一連の処理を終了する。

図４１は、実施例２におけるデータ待避部の動作手順を示すフローチャートである。図４１のフローチャートは、電源停止時にデータ待避部９０６によって実行される処理内容を表している。

図４１において、データ待避部９０６は、まず、アドレスを０に設定すると（ステップＳ４１０１）、復元データ生成部９０５に復元対象のローカルメモリとアドレスを指示する（ステップＳ４１０２）。さらに、データ待避部９０６は、復元データ生成部９０５から受け取ったデータを共有メモリ１０４に待避する（ステップＳ４１０３）。

その後、データ待避部９０６は、停止後のＣＰＵ数が規定値以上か否かを判断する（ステップＳ４１０４）。ステップＳ４１０４において、ＣＰＵ数が規定値以上と判断された場合（ステップＳ４１０４：Ｙｅｓ）、データ待避部９０６は、復元に使ったパリティデータの場所をパリティ再構築部９０３に通知する（ステップＳ４１０５）。

その後、データ待避部９０６は、アドレスをインクリメントし（ステップＳ４１０６）、データ領域の待避が完了したか否かを判断する（ステップＳ４１０７）。なお、ステップＳ４１０４において、ＣＰＵ数が規定値以上ではないと判断された場合（ステップＳ４１０４：Ｎｏ）、データ待避部９０６は、ステップＳ４１０５の処理を行わずに、ステップＳ４１０６の処理に移行してアドレスをインクリメントする。

その後、データ待避部９０６は、ステップＳ４１０７において、データ領域の待避が完了するまでステップＳ４１０２の処理に戻り、インクリメント後のアドレスを対象とした処理を繰り返す（ステップＳ４１０７：Ｎｏのループ）。

ステップＳ４１０７において、データ領域の待避が完了したと判断された場合（ステップＳ４１０７：Ｙｅｓ）、データ待避部９０６は、停止後のＣＰＵ数が規定値以下か否かを判断する（ステップＳ４１０８）。ステップＳ４１０８において、ＣＰＵ数が規定値以下であると判断された場合（ステップＳ４１０８：Ｙｅｓ）、データ待避部９０６は、パリティ再構築部９０３に待避完了を通知して（ステップＳ４１０９）、一連の処理を終了
する。

なお、ステップＳ４１０８において、停止後のＣＰＵ数が規定値以下ではないと判断された場合（ステップＳ４１０８：Ｎｏ）、データ待避部９０６は、ステップＳ４１０９の処理を行わずに、そのまま一連の処理を終了する。

図４２は、実施例２における復元データ生成部の動作手順を示すフローチャートである。図４２のフローチャートは、電源停止時に復元データ生成部９０５によって実行される処理内容を表している。

図４２において、復元データ生成部９０５は、まず、指示された復元対象に対応するデータを読み込む（ステップＳ４２０１）。その後、復元データ生成部９０５は、復元データを生成し（ステップＳ４２０２）、一連の処理を終了する。

図４３は、パリティ再構築部の動作手順を示すフローチャートである。図４３のフローチャートは、パリティ再構築部９０３による通知内容に応じたパリティデータに関する処理を表している。図４３の各処理を実行することによって、パリティ再構築部９０３は、適切なパリティデータを生成すると共に、生成したパリティデータを適切な箇所に格納することができる。

図４３において、パリティ再構築部９０３は、他の機能部からの、なんらかの通知の受信をトリガに動作を開始する。まず、パリティ再構築部９０３が受信する通知としては、パリティデータの生成の通知、待避完了の通知、復元完了の通知の３種類がある。したがって、いずれの通知を受信したかに応じてパリティ再構築部９０３の動作内容も変化する。

まず、パリティデータの生成が通知された場合、パリティ再構築部９０３は、パリティ生成部９０２に通知されたパリティの場所を指示する（ステップＳ４３０１）。その後、パリティ再構築部９０３は、生成されたパリティデータを書き込み（ステップＳ４３０２）、一連の処理を終了する。

次に、待避完了が通知された場合、パリティ再構築部９０３は、停止前後の稼働中のローカルメモリ数から未再構成の領域を算出する（ステップＳ４３０３）。さらに、パリティ再構築部９０３は、パリティ生成部９０２にパリティの場所を指示すると（ステップＳ４３０４）、生成されたパリティデータを書き込む（ステップＳ４３０５）。

その後、パリティ再構築部９０３は、未再構成のデータがあるか否かを判断する（ステップＳ４３０６）。ステップＳ４３０６において、未再構成のデータがあると判断された場合（ステップＳ４３０６：Ｙｅｓ）、パリティ再構築部９０３は、ステップＳ４３０４の処理に戻り、未再構成のデータに対する処理を継続する。

一方、ステップＳ４３０６において、未再構成のデータがないと判断されると（ステップＳ４３０６：Ｎｏ）、パリティ再構築部９０３は、ローカルメモリ稼働委情報テーブル３８０１を停止に更新して（ステップＳ４３０７）、一連の処理を終了する。

また、復元完了が通知された場合、パリティ再構築部９０３は、稼働ローカルメモリ数から復帰したローカルメモリの未再構成領域を算出する（ステップＳ４３０８）。その後、パリティ再構築部９０３は、パリティ生成部９０２にパリティの場所を指示し（ステップＳ４３０９）、生成されたパリティデータを書き込む（ステップＳ４３１０）。

そして、パリティ再構築部９０３は、未再構成のデータがあるか否かを判断する（ステップＳ４３１１）。ステップＳ４３１１において、未再構成のデータがあると判断された場合（ステップＳ４３１１：Ｙｅｓ）、パリティ再構築部９０３は、ステップＳ４３０９の処理に戻り、未再構成のデータに対する処理を継続する。

一方、ステップＳ４３１１において、未再構成のデータがないと判断されると（ステップＳ４３１１：Ｎｏ）、パリティ再構築部９０３は、ローカルメモリ稼働情報テーブル３８０１を稼働中に更新して（ステップＳ４３１２）、一連の処理を終了する。

図４４は、パリティ生成部の動作手順を示すフローチャートである。図４３のフローチャートは、パリティ生成部９０２によって実行される処理内容を表している。

図４４において、パリティ生成部９０２は、まず、指示されたパリティに対応するデータを読み込む（ステップＳ４４０１）。その後、パリティ生成部９０２は、パリティデータを生成し（ステップＳ４４０２）、一連の処理を終了する。

以上、図４０〜４４にて説明したように、コマンド受信部９０４は、ＲＡＩＤコントローラ３８００では、電源停止が通知されると、まずコマンド受信部９０４が受信したコマンドの情報に応じてローカルメモリ稼働情報テーブル３８０１を更新する。また、データ待避部９０６に停止したローカルメモリの内容の待避を指示する。また、停止後の稼働ローカルメモリ数が規定値以上の場合はパリティ再構築部９０３にも指示を出し、平行してパリティデータの再構築を行う。

また、パリティ再構築部９０３では、データ復帰部９０７によって待避領域から復帰したデータに対応するパリティデータを再構築する。そして、待避領域から復帰したデータの再構築が終了すると、復帰したローカルメモリのパリティ領域に対応するパリティデータを再構築する。

そして、データ待避部９０６およびパリティ再構築部９０３では、データ待避部９０６が停止されたローカルメモリのデータ領域の先頭から待避を行う。このとき、データ復帰部９０７を利用して、データを復元した後、あらかじめ定められた待避領域へ待避していく。データ復帰部９０７では、データ待避部９０６から指示されたデータを復元するためのパリティデータとこれに対応するデータを稼働中のローカルメモリから読み込んで停止したローカルメモリのデータを復帰する。

また、パリティ再構築部９０３ではここで待避が完了したパリティデータ領域にパリティ生成部９０２を利用して順次パリティデータを再構築していく。停止したローカルメモリの全データ領域の待避が完了したら、残りの領域に対しても順次パリティデータを生成していく。

＜電源復帰時の動作＞
図４５は、実施例２における電源復帰時のＯＳの動作手順を示すフローチャートである。図４５のフローチャートは、実施例２において、マルチコアプロセッサ３７００のなかの停止中のＣＰＵの電源を復帰させる際のＯＳの処理内容を示している。

図４５において、ＯＳは、電源停止からの復帰をトリガに処理を開始する。まず、ＯＳは、他のプロセッサのローカルメモリを待避中か否かを判断する（ステップＳ４５０１）。ステップＳ４５０１において、他のプロセッサのローカルメモリを待避中であると判断された場合（ステップＳ４５０１：Ｙｅｓ）、ＯＳは、待避が完了するまで待機状態となる（ステップＳ４５０２）。

ＯＳは、他のプロセッサのローカルメモリが待避中ではない（ステップＳ４５０１：Ｎｏ）、もしくは、待避が完了するまで待つと（ステップＳ４５０２）、ＲＡＩＤコントローラ３８００に復帰を通知する（ステップＳ４５０３）。その後、ＯＳは、プロセッサのレジスタの内容を復元する（ステップＳ４５０４）。

さらに、ＯＳは、ＲＡＩＤコントローラ３８００によりローカルメモリが復元されるまで待ち（ステップＳ４５０５）、他のプロセッサに復帰を通知する（ステップＳ４５０６）。その後、ＯＳは、通常の処理を再開させて（ステップＳ４５０７）、一連の復帰処理を終了する。

以上説明したように、実施例２では、ＣＰＵへの電力供給を再開する場合は、電力供給が再開されたＣＰＵによって実行されているＯＳよりレジスタの内容を復元する。また、ＯＳは、同時にＲＡＩＤコントローラ３８００に自身の復帰を通知するため、ＲＡＩＤコントローラ３８００による復元の完了を待って停止前の処理を再開することができる。

図４６は、データ復帰部の動作手順を示すフローチャートである。図４６は、電源復帰時におけるデータ復帰部９０７にて実行される処理内容を表している。

図４６において、データ復帰部９０７は、まず、ローカルメモリ稼働情報テーブル３８０１を確認し（ステップＳ４６０１）、待避中か否かを判断する（ステップＳ４６０２）。ステップＳ４６０２において、ローカルメモリ稼働情報テーブル３８０１が待避中と判断された場合（ステップＳ４６０２：Ｙｅｓ）、データ復帰部９０７は、データ待避部９０６に待避中止を通知する（ステップＳ４６０３）。

その後、データ復帰部９０７は、データ待避部９０６から最後に待避したアドレスを取得し（ステップＳ４６０４）、その後、アドレスを０に、終了アドレスをステップＳ４６０４によって取得したアドレスに設定する（ステップＳ４６０５）。

一方、ステップＳ４６０２において、待避中でないと判断された場合（ステップＳ４６０２：Ｎｏ）、データ復帰部９０７は、アドレスを０、終了アドレスをデータ領域の最終アドレスに設定する（ステップＳ４６０６）。

ステップＳ４６０５もしくはステップＳ４６０６において、アドレス設定が行われると、データ復帰部９０７は、待避したデータをローカルメモリに復帰させる（ステップＳ４６０７）。そして、データ復帰部９０７は、復元後のＣＰＵ数が規定値以上か否かを判断する（ステップＳ４６０８）。

ステップＳ４６０８において、復元後のＣＰＵ数が規定値以上と判断された場合（ステップＳ４６０８：Ｙｅｓ）、データ復帰部９０７は、復帰したデータに対応するパリティデータをパリティ再構築部９０３に通知する（ステップＳ４６０９）。その後、データ復帰部９０７は、アドレスをインクリメントする（ステップＳ４６１０）。

一方、ステップＳ４６０８において、復元後のＣＰＵ数が規定値以上ではないと判断された場合（ステップＳ４６０８：Ｎｏ）、データ復帰部９０７は、ステップＳ４６０９の処理を行わずに、ステップＳ４６１１の処理に移行する。

次に、データ復帰部９０７は、終了アドレスに到達したか否かを判断する（ステップＳ４６１１）。ステップＳ４６１１において、終了アドレスに到達していない場合（ステップＳ４６１１：Ｎｏ）、データ復帰部９０７は、ステップＳ４６０７に戻り、インクリメント後のアドレスを対象に処理を行う。

その後、ステップＳ４６１１において、終了アドレスに到達したと判断された場合（ステップＳ４６１１：Ｙｅｓ）、データ復帰部９０７は、復元後のＣＰＵ数が規定値以上か否かを判断する（ステップＳ４６１２）。ステップＳ４６１２において、ＣＰＵ数が規定値以上であると判断された場合（ステップＳ４６１２：Ｙｅｓ）、データ復帰部９０７は、パリティ再構築部９０３に復元終了を通知して（ステップＳ４６１３）、一連の処理を終了する。一方、ステップＳ４６１２において、ＣＰＵ数が規定値以上ではないと判断された場合（ステップＳ４６１２：Ｎｏ）、データ復帰部９０７は、ステップＳ４６１３の処理を行わずに、一連の処理を終了する。

以上説明したように、実施例２のデータ復帰部９０７は、ローカルメモリ稼働情報テーブル３８０１を参照して復帰したローカルメモリが直前に停止されたものでなければ全データは待避済みと判断する。したがって、データ復帰部９０７は、待避されたデータからローカルメモリに復元する。また、直前に停止されたＣＰＵの場合は、データ待避部９０６は、ローカルメモリ稼働情報テーブル３８０１を参照する。そして、未待避のデータがある場合は復元データ生成部９０５によって、未処理の再構築前のパリティデータからローカルメモリへデータを復元することによって、漏れなくデータを復帰することができる。

（実施例３）
実施例３では、実施例２と、同じく図５１に示したマルチコアプロセッサ３７００の構成を利用する。しかしながら、実施例２と異なり、ＲＡＩＤコントローラ３８００にローカルメモリの待避復帰状況を記録する待避復帰情報４８０１（図４８参照）を追加する。待避復帰情報４８０１にローカルメモリの待避復帰状況を記録してメモリアクセス監視部９０１に読込処理と書込処理の双方を監視させることによって、電源復帰時のローカルメモリへのデータ復元の高速化が期待できる。

＜電源停止時の動作＞
図４７は、実施例３における電源復帰時のＯＳの動作手順を示すフローチャートである。図４７のフローチャートは、マルチコアプロセッサ３７００内のいずれかのＣＰＵの電源停止時にＯＳからＲＡＩＤコントローラ４８００（図３７参照）へ出力される指示内容と、その手順を表している。

図４７において、マルチコアプロセッサのＯＳは、電源停止からの復帰指示をトリガに動作を開始する。まず、ＯＳは、ＲＡＩＤコントローラ４８００に復帰を通知する（ステップＳ４７０１）。つぎに、ＯＳは、復帰したプロセッサ（たとえばＣＰＵ＃１）のレジスタの内容を復元すると（ステップＳ４７０２）、他のプロセッサに復帰を通知する（ステップＳ４７０３）。その後、ＯＳは、復帰したプロセッサの通常の処理を再開させ（ステップＳ４７０４）、電源復帰時の一連の動作を終了する。以上説明したように、実施例３の場合、電源復帰時のＯＳは、ＲＡＩＤコントローラ４８００によるローカルメモリの内容の復帰を待たずに処理を開始する。

図４８は、実施例３におけるＲＡＩＤコントローラの内部構成を示すブロック図である。図４８に示したように、実施例３の場合、ＲＡＩＤコントローラ４８００は、実施例２のＲＡＩＤコントローラ３８００に待避復帰情報４８０１が追加された構成になっている。

また、ＲＡＩＤコントローラ４８００の場合、メモリアクセス監視部９０１では、実施例２にて説明した監視処理に加えて、復帰中のローカルメモリへのアクセスを監視することができる。復帰中のローカルメモリへのアクセスを監視することによって、ＲＡＩＤコントローラ４８００は、復帰前のローカルメモリデータへのリードがあった場合には、ＲＡＩＤコントローラ４８００が対象のデータを先に復帰して値を返すことができる。そして、ＲＡＩＤコントローラ４８００は、ライトがあった場合には、通常通りパリティデータを更新して、対象となるデータを復帰しないように待避復帰情報を更新することができる。

図４９は、メモリアクセス監視部の動作手順を示すフローチャートである。図４９のフローチャートは、メモリアクセス監視部９０１によって実行される処理内容を表している。

図４９において、メモリアクセス監視部９０１は、いずれかのローカルメモリへのアクセスの検出をトリガに動作を開始する。そして、メモリアクセス監視部９０１は、まず、ローカルメモリ稼働情報テーブル３８０１の対象エントリを確認する（ステップＳ４９０１）。次に、メモリアクセス監視部９０１は、ステップＳ４９０１において確認したエントリが復帰中か否かを判断する（ステップＳ４９０２）。

ステップＳ４９０２において、確認したエントリが復帰中であると判断された場合（ステップＳ４９０２：Ｙｅｓ）、続いて、メモリアクセス監視部９０１は、確認したエントリがいずれかのローカルメモリへのライトアクセスか否かを判断する（ステップＳ４９０３）。ステップＳ４９０３において、確認したエントリがライトアクセスであると判断された場合（ステップＳ４９０３：Ｙｅｓ）、メモリアクセス監視部９０１は、対応するパリティデータの場所を算出する（ステップＳ４９０４）。

ステップＳ４９０４によってパリティデータの場所が算出されると、メモリアクセス監視部９０１は、パリティ生成部９０２に算出した場所を通知する（ステップＳ４９０５）。その後、メモリアクセス監視部９０１は、生成されたパリティデータをローカルメモリに書き込み（ステップＳ４９０６）、書き込みデータに対応する待避復帰情報４８０１を復帰に更新して（ステップＳ４９０７）、一連の処理を終了する。

一方、ステップＳ４９０３において、確認したエントリがライトアクセスではないと判断された場合（ステップＳ４９０３：Ｎｏ）、メモリアクセス監視部９０１は、対応する待避復帰情報４８０１を確認する（ステップＳ４９０８）。そして、メモリアクセス監視部９０１は、待避復帰情報４８０１を確認した結果が、復帰状態か否かを判断する（ステップＳ４９０９）。

ステップＳ４９０９において、確認した結果が復帰状態であった場合（ステップＳ４９０９：Ｙｅｓ）、メモリアクセス監視部９０１は、一連の処理を終了する。一方、確認した結果が復帰状態ではなかった場合（ステップＳ４９０９：Ｎｏ）、メモリアクセス監視部９０１は、今回のアクセスがリードアクセスであると判断して、以後の処理を行う。

まず、メモリアクセス監視部９０１は、復元データ生成部９０５にリード先の場所を通知する（ステップＳ４９１０）。その後、メモリアクセス監視部９０１は、復元したデータをアクセス元に返し（ステップＳ４９１１）、復元したデータをローカルメモリに書き込む（ステップＳ４９１２）。したがって、メモリアクセス監視部９０１は、対応する待機復帰情報４８０１を復帰に更新する（ステップＳ４９１３）。

その後、メモリアクセス監視部９０１は、復元後のＣＰＵ数が規定値以上か否かを判断する（ステップＳ４９１４）。ステップＳ４９１４において、ＣＰＵ数が規定値以上と判断された場合（ステップＳ４９１４：Ｙｅｓ）、メモリアクセス監視部９０１は、復帰したデータに対応するパリティデータをパリティ再構築部９０３に通知して（ステップＳ４９１５）、一連の処理を終了する。一方、ステップＳ４９１４において、ＣＰＵ数が規定値上ではないと判断された場合（ステップＳ４９１４：Ｎｏ）、メモリアクセス監視部９０１は、そのまま一連の処理を終了する。

また、ステップＳ４９０２において、確認したエントリが復帰中でないと判断された場合（ステップＳ４９０２：Ｎｏ）、メモリアクセス監視部９０１は、確認したエントリがいずれかのローカルメモリへのライトアクセスか否かを判断する（ステップＳ４９１６）。ステップＳ４９１６において、確認したエントリがライトアクセスであると判断された場合（ステップＳ４９１６：Ｙｅｓ）、メモリアクセス監視部９０１は、対応するパリティデータの場所を算出する（ステップＳ４９１７）。

ステップＳ４９１７によってパリティデータの場所が算出されると、メモリアクセス監視部９０１は、パリティ生成部９０２に算出した場所を通知する（ステップＳ４９１８）。その後、メモリアクセス監視部９０１は、生成されたパリティデータをローカルメモリに書き込み（ステップＳ４９１９）、一連の処理を終了する。一方、ステップＳ４９１６において、確認したエントリがライトアクセスではないと判断された場合（ステップＳ４９１６：Ｎｏ）、メモリアクセス監視部９０１は、そのまま一連の処理を終了する。

図５０は、実施例３におけるデータ待避部の動作手順を示すフローチャートである。図５０のフローチャートは、データ待避部９０６によって実行される処理内容を表している。

図５０において、データ待避部９０６は、まず、アドレスを０に設定し（ステップＳ５００１）、復元データ生成部９０５に復元対象のローカルメモリとアドレスを指示する（ステップＳ５００２）。その後、データ待避部９０６は、復元データ生成部９０５から受け取ったデータを共有メモリ１０４に待避する（ステップＳ５００３）。

続いて、データ待避部９０６は、停止後のＣＰＵ数が規定値以上か否を判断する（ステップＳ５００４）。ステップＳ５００４において、ＣＰＵ数が規定値以上であると判断された場合（ステップＳ５００４：Ｙｅｓ）、データ待避部９０６は、復元に使ったパリティデータの場所をパリティ再構築部９０３に通知する（ステップＳ５００５）。

その後、データ待避部９０６は、対応する待避復帰情報４８０１を待避に更新し（ステップＳ５００６）、アドレスをインクリメントする（ステップＳ５００７）。一方、ステップＳ５００４において、ＣＰＵ数が規定値以上ではないと判断された場合（ステップＳ５００４：Ｎｏ）、データ待避部９０６は、ステップＳ５００５〜Ｓ５００６の処理を行わずに、そのままステップＳ５００７において、アドレスをインクリメントする。

ステップＳ５００７の処理の後、データ待避部９０６は、データ領域の待避が完了したか否かを判断し（ステップＳ５００８）、待避が完了していると判断された場合には（ステップＳ５００８：Ｙｅｓ）、さらに、停止後のＣＰＵ数が規定値以下か否かを判断する（ステップＳ５００９）。

なお、ステップＳ５００８において、データ領域の待避が完了していないと判断された場合（ステップＳ５００８：Ｎｏ）、データ待避部９０６は、ステップＳ５００２の処理に移行して、次のアドレスを対象にした処理を行う。そして、データ待避部９０６は、ステップＳ５００９において、停止後のＣＰＵ数が規定値以下と判断された場合（ステップＳ５００９：Ｙｅｓ）、パリティ再構築部９０３に待避完了を通知して（ステップＳ５０１０）、一連の処理を終了する。

一方、ステップＳ５００９において、停止後のＣＰＵ数が規定値以下ではないと判断された場合（ステップＳ５００９：Ｎｏ）、データ待避部９０６は、そのまま一連の処理を終了する。

図５１は、実施例３における復元データ生成部の動作手順を示すフローチャートである。図５１のフローチャートは、実施例３の復元データ生成部９０５によって実行される処理内容を表している。

図５１において、復元データ生成部９０５は、まず、ローカルメモリ稼働情報テーブル３８０１を確認する（ステップＳ５１０１）。その後、復元データ生成部９０５は、アドレスを０、終了アドレスを、データ領域の最終アドレスに設定する（ステップＳ５１０２）。

続いて、復元データ生成部９０５は、稼働情報が待避中か否かを判断する（ステップＳ５１０３）。ステップＳ５１０３において、稼働情報が待避中と判断された場合（ステップＳ５１０３：Ｙｅｓ）、復元データ生成部９０５は、対象の待避復帰情報４８０１を確認し（ステップＳ５１０４）、対象データが待避中か否かを判断する（ステップＳ５１０
５）。

ステップＳ５１０５において、対象データが待避中であると判断された場合（ステップＳ５１０５：Ｙｅｓ）、ステップＳ５１０９の処理に移行する。一方、ステップＳ５１０５において、対象データが待避中でないと判断された場合（ステップＳ５１０５：Ｎｏ）、復元データ生成部９０５は、待避したデータをローカルメモリに復帰し（ステップＳ５１０６）、その後、復元後のＣＰＵ数が規定値以上か否かを判断する（ステップＳ５１０７）。

また、ステップＳ５１０３において、稼働情報が待避中ではないと判断された場合（ステップＳ５１０３：Ｎｏ）にも、復元データ生成部９０５は、ステップＳ５１０６の処理に移行して待避したデータをローカルメモリに復帰する。

ステップＳ５１０７において、復元後のＣＰＵ数が規定値以上であると判断された場合（ステップＳ５１０７：Ｙｅｓ）、復元データ生成部９０５は、復帰したデータに対応するパリティデータをパリティ再構築部９０３に通知する（ステップＳ５１０８）。なお、ステップＳ５１０７において、復元後のＣＰＵ数が規定値以上でないと判断された場合（ステップＳ５１０７：Ｎｏ）、復元データ生成部９０５は、ステップＳ５１０９の処理に移行する。

その後、復元データ生成部９０５は、アドレスをインクリメントして（ステップＳ５１０９）、インクリメント後のアドレスが終了アドレスに到達したか否かを判断する（ステップＳ５１１０）。ステップＳ５１１０において、終了アドレスに到達していない場合には（ステップＳ５１１０：Ｎｏ）、復元データ生成部９０５は、ステップＳ５１０３の処理に戻って、次のアドレスに対しての処理を行う。

その後、ステップＳ５１１０において、終了アドレスに到達したと判断された場合（ステップＳ５１１０：Ｙｅｓ）、復元データ生成部９０５は、復元後のＣＰＵ数が規定値以上か否かを判断する（ステップＳ５１１１）。

そして、ＣＰＵ数が規定値以上と判断された場合（ステップＳ５１１１：Ｙｅｓ）、復元データ生成部９０５は、パリティ再構築部９０３に復元終了を通知して（ステップＳ５１１２）、一連の処理を終了する。なお、ステップＳ５１１１において、ＣＰＵ数が規定値以上でないと判断された場合（ステップＳ５１１１：Ｎｏ）、復元データ生成部９０５は、そのまま一連の処理を終了する。

以上説明したように、実施例３の場合、メモリアクセス監視部９０１は、また、データ待避部９０６では、データ待避時に待避復帰情報４８０１を更新する。したがって、データ復帰部９０７では、待避復帰情報４８０１を参照して未復帰の情報を復帰すると共に、待避復帰情報を更新することができる。したがって、誤ったデータを待避させるような事態を防ぐと共に、実施例２と比較してより高速な電源停止を実現することができる。

（電力の比較）
図５２は、データ復元処理を採用した場合の電力比較例を示す説明図である。マルチコアプロセッサの場合、あらかじめ配置されるＣＰＵ数や、同時に稼働させるＣＰＵ数も様々であり、使用状況に応じて電力効率は大きく変わる。しかしながら、従来の技術では、こまめな電源のＯＮ／ＯＦＦは、ローカルメモリに格納されているデータの待避時間を考慮すると待避時間の発生によって十分な省電力効果が得られないことが多かった。

そこで、図５２を用いて、本実施の形態にかかるデータ復元処理を適用したマルチコアプロセッサと、それ以外のマルチコアプロセッサとの簡単な消費電力の比較結果を例示した。ここではＣＰＵを４つ備えたマルチコアプロセッサについて説明する。

図５２の上段はローカルメモリの電源を切らない場合の電力を、中断は、従来手法（データを待避するまで電力を供給する）で電力を切る場合の電力を、下段は、本実施の形態にかかるデータ復元処理を利用した場合の電力をそれぞれ表している。また、本実施の形態にかかるデータ復元処理を利用した場合、ＣＰＵが３つ以上稼働中であれば、パリティデータを生成するように設定している。

また、図５２では、上段以外は、左から右にかけて４つのＣＰＵが稼働している場合、３つのＣＰＵが稼働している場合、２つのＣＰＵが稼働している場合、１つのＣＰＵが稼働している場合の電力変化を表している。

図５２において、常時４つのＣＰＵが稼働中の上段の手法では常に電力：４（相対値）が消費される。そして、中段の従来手法の場合、稼働中のＣＰＵ数に応じた電力４→３→２→１の電力が消費される。当然のことながら、消費する電力は最小１まで抑えることができる。しかしながら、稼働中のＣＰＵの数の変更に要する処理速度が遅く、マルチコアプロセッサとしての機能の低下が避けられない。

そして、下段の本実施の形態にかかるデータ復元処理では、パリティデータを作成してパリティの領域に格納するため、稼働しているＣＰＵの数が同じであれば、電源を切らない手法や、従来手法よりも電力の消費が大きくなってしまっている。しかしながら、ＣＰＵの数を変更させる場合であっても、データの待避を行わないため、処理速度が速く、即座に新たなＣＰＵ数に応じた処理に移行することができる。

したがって、本実施の形態にかかるデータ復元処理は、特にＣＰＵ数が比較的少なく、なおかつ、稼働させるＣＰＵ数が頻繁に変化するようなマルチコアプロセッサへ適用すれば、電力効率の高いシステムの提供が期待できる。

以上説明したように、本実施の形態にかかるマルチコアプロセッサシステム、制御方法および制御プログラムによれば、揮発性メモリ内に格納されていたデータが消失しても、あらかじめ格納しておいたパリティデータによって揮発性メモリ内に格納されたデータを復元することができる。したがって、ローカルメモリの電源停止時に事前にローカルメモリの内容を待避しておく必要がなくなるため、ローカルメモリの電源停止動作を高速化することができる。

また、上記技術は、さらに、稼働中の揮発性メモリ数が変化した場合には、格納可能な揮発性メモリの数に応じてパリティデータを作成する。したがって、プロセッサ数が頻繁に変化するような環境であっても、適切な構成のパリティデータを作成することができる。

また、上記技術では、さらに、一旦電源停止となったプロセッサが始動する場合には、共有メモリに復元されたデータを自動的に揮発性メモリに復帰することもできる。また、プロセッサが始動した際に、共有メモリ内に復元が済んでいないデータに関しては、パリティデータを利用して再構成した後に揮発性メモリに復帰する。したがって、プロセッサの停止や再開が頻繁に起こっても、揮発性メモリに格納され、一旦消失したデータを余すことなく復元することができる。

また、上記技術では、さらに、稼働中のプロセッサがアクセスする揮発性メモリが停止中である場合には、揮発性メモリに格納されていたデータが再構成されているか否かに応じて、プロセッサのアクセス先を変更することができる。また、揮発性メモリに格納されていたデータが再構成されていなかった場合には、アクセス対象となるデータの再構成を行いプロセッサによるアクセスを支援する。したがって、マルチコアプロセッサの中に停止中のプロセッサが存在しても稼働中の他のプロセッサは他のプロセッサの稼働状態を考慮することなく通常と同じ手順で所望のデータにアクセスすることができる。

また、上記技術では、さらに、稼働中のプロセッサ数に応じて、揮発性メモリに格納されているデータの待避処理の手法を変更することができる。すなわち、稼働中のプロセッサ数が多く、揮発性メモリにパリティデータを格納しても、各プロセッサの処理速度を低下させない場合には、パリティデータを利用した待避処理を採用して高速な電源停止を実現する。稼働中のプロセッサ数が少なく、パリティデータの格納によって揮発性メモリの容量が圧迫され、プロセッサの処理速度の低下を招いてしまう恐れのある場合には、パリティデータを格納せずに、従来の手法によってデータを待避する。したがって、稼働中のプロセッサ数に応じて最も効率のよい手法を利用するため、マルチコアプロセッサの処理速度を想定値以内に保つことができる。

なお、本実施の形態で説明した制御方法は、あらかじめ用意されたプログラムをパーソナル・コンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。本制御プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本制御プログラムは、インターネットなどのネットワークを介して配布してもよい。

また、本実施の形態で説明したデータ復元装置１１０は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣ（以下、単に「ＡＳＩＣ」と称す。）やＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）によっても実現することができる。具体的には、たとえば、上述したデータ復元装置１１０の機能（停止検出部６０１〜復帰部６０６）をＨＤＬ記述によって機能定義し、そのＨＤＬ記述を論理合成してＡＳＩＣやＰＬＤに与えることにより、データ復元装置１１０を製造することができる。

１００，６００ マルチコアプロセッサ
１０１ 電源
１０２ ローカルメモリバス
１０３ 共有メモリバス
１０４ 共有メモリ
１１０ データ復元装置
６０１ 停止検出部
６０２ 復元部
６０３ 作成部
６０４ 格納部
６０５ 始動検出部
６０６ 復帰部
９０１ メモリアクセス監視部
９０２ パリティ生成部
９０３ パリティ再構築部
９０４ コマンド受信部
９０５ 復元データ生成部
９０６ データ待避部
９０７ データ復帰部

Claims (3)

1. 複数のコアと、
   前記複数のコアそれぞれに対応してデータを記録する複数のローカルメモリと、
   前記複数のコアが共通にアクセス可能な共有メモリと、
   前記複数のローカルメモリに記録されたデータを前記共有メモリに復元するデータ復元装置と
   を有するマルチプロセッサシステムであって、前記データ復元装置は、
   前記複数のコアのうちの第１のコアに対応する第１のローカルメモリへの電源供給停止の指示に応じ、前記第１のローカルメモリを除く複数のローカルメモリのいずれかに記録されたパリティデータに基づいて、前記第１のローカルメモリに記録されていたデータを前記共有メモリに復元する
   マルチコアプロセッサシステム。
2. 複数のコアと、前記複数のコアそれぞれに対応してデータを記録する複数のローカルメモリと、前記複数のコアが共通にアクセス可能な共有メモリを有するマルチコアプロセッサシステムの制御方法であって、前記マルチコアプロセッサシステムが、
   前記複数のコアのうちの第１のコアに対応する第１のローカルメモリへの電源供給停止の指示を検出する処理と、
   検出した前記第１のローカルメモリを除く複数のローカルメモリのいずれかに記録されたパリティデータに基づいて、前記第１のローカルメモリに記録されていたデータを前記共有メモリに復元する処理と
   を実行するマルチコアプロセッサシステムの制御方法。
3. 複数のコアと、前記複数のコアそれぞれに対応してデータを記録する複数のローカルメモリと、前記複数のコアが共通にアクセス可能な共有メモリを有するマルチコアプロセッサシステムの制御プログラムであって、前記マルチコアプロセッサシステムに、
   前記複数のコアのうちの第１のコアに対応する第１のローカルメモリへの電源供給停止の指示を検出する処理と、
   検出した前記第１のローカルメモリを除く複数のローカルメモリのいずれかに記録されたパリティデータに基づいて、前記第１のローカルメモリに記録されていたデータを前記共有メモリに復元する処理と
   を実行させるマルチコアプロセッサシステムの制御プログラム。

Images