(57)【要約】【課題】  アプリケーション・プログラミング・インタフェース単位で従プロセッサの電力レベルを設定し、性能と消費電力削減とを適切選択する。【解決手段】  メイン処理を行う主プロセッサＡ  １と、この主プロセッサからの依頼を受けて動作する従プロセッサとからなるマルチプロセッサ・システムにおいて、上記従プロセッサＢ  ２が処理するアプリケーション・プログラミング・インタフェース単位で上記従プロセッサの動作モードを管理する実行モード管理テーブル１４と、上記実行モード管理テーブルで管理される従プロセッサの動作モードに対応してこの従プロセッサの動作クロックまたは印加電源電圧を制御規定し、上記主プロセッサからの依頼が無い場合は上記従プロセッサを停止状態に制御規定する電源管理部１５と、を備えた。【選択図】        図１
2006163970.tif 000002
【特許請求の範囲】
【請求項１】
メイン処理を行う主プロセッサと、該主プロセッサからの依頼を受けて動作する従プロセッサとからなるマルチプロセッサ・システムにおいて、
上記従プロセッサが処理するアプリケーション・プログラミング・インタフェース単位で上記従プロセッサの動作モードを管理する実行モード管理テーブルと、
上記実行モード管理テーブルで管理される従プロセッサの動作モードに対応して該従プロセッサの動作クロックまたは印加電源電圧を制御規定し、上記主プロセッサからの依頼が無い場合は上記従プロセッサを停止状態に制御規定する電源管理部と、を備えたことを特徴とするマルチプロセッサ・システム。
【請求項２】
従プロセッサの電圧またはクロックを制御規定する電源管理部は、従プロセッサ側に備えたことを特徴とする請求項１記載のマルチプロセッサ・システム。
【請求項３】
電源管理部は、主プロセッサが、遠隔手続呼出要求メッセージに従プロセッサの動作モードを載せて送信し、上記従プロセッサは該遠隔手続呼出要求メッセージに基いて従プロセッサの電圧またはクロックを制御規定するようにしたことを特徴とする請求項２記載のマルチプロセッサ・システム。
【請求項４】
実行モード管理テーブルは、遠隔手続呼出インタフェース定義から生成したテーブルとしたことを特徴とする請求項１記載のマルチプロセッサ・システム。
【請求項５】
主プロセッサによりメイン処理を行い、上記主プロセッサからの依頼を受けて従プロセッサが処理動作を行うマルチプロセッサによる動作の制御方法において、
上記従プロセッサが処理するアプリケーション・プログラミング・インタフェース単位で上記従プロセッサの動作モードを管理する実行モード管理テーブルを参照する管理テーブル参照ステップと、
上記実行モード管理テーブルを参照して管理される従プロセッサの動作モードを知り、対応した該従プロセッサの動作クロックまたは印加電源電圧を制御規定し、上記主プロセッサからの依頼が無い場合は上記従プロセッサを停止状態に制御規定する電源管理ステップと、を備えたことを特徴とするマルチプロセッサ制御方法。
【請求項６】
主プロセッサによりメイン処理を行い、上記主プロセッサからの依頼を受けて従プロセッサが処理動作を行うマルチプロセッサ・システムに用いられるプログラムを記録した記録媒体であって、
上記従プロセッサが処理するアプリケーション・プログラミング・インタフェース単位で上記従プロセッサの動作モードを管理するステップと、
上記動作モードを管理するステップで管理される従プロセッサの動作モードに対応して該従プロセッサの動作クロックまたは印加電源電圧を制御規定し、上記主プロセッサからの依頼が無い場合は上記従プロセッサを停止状態に制御規定する電源管理ステップと、を計算機に実行させるプログラムとして記録したことを特徴とする計算機読み取り可能なマルチプロセッサ制御プログラム記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数のプロセッサによりアプリケーションを実行するシステムにおいて、主処理を実行するプロセッサの動作状態に応じて他のプロセッサの動作状態を制御して消費電力を抑えるシステム、方法に関するものである。
【背景技術】
【０００２】
従来からマルチプロセッサシステムにおける省電力制御方式として、プロセッサの動作クロックを抑えることで、単位時間あたりの消費電力を削減する方式が提案されている。例えば第１の従来例として特許文献１では、処理単位をタスクとし、周期リアルタイムタスクが規定された時間制約のもとで処理を満了するために必要十分なプロセッサの動作クロックを、ＯＳ（オペレーティング・システム）のタスク管理において算出、設定している。また、算出された動作クロックに対応する動作電圧も可能な限り低く抑えることにより、省電力効果を高くしている。
一方、第２の従来例として特許文献２では、ユーザーからアプリケーション実行時のプロセッサ動作クロック情報を制御可能とし、アプリケーション毎に動作クロックを切り替えることで、動作速度とバッテリー持続時間のトレードオフをユーザーが選択可能にしている。
【特許文献１】特開２００２−９９４３３号公報
【特許文献２】特開平１０−３３３７７３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
第１の従来例としての特許文献１では、周期リアルタイムタスクの時間制約に従い、動作クロックを変えることで消費電力を最小限に抑えるとしている。マルチプロセッサシステムにおいて、他プロセッサへの処理要求をＲＰＣ（Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ  遠隔手続呼出）で行うとした場合、処理方式はイベント駆動型となる。ＲＰＣでは、遠隔の呼び出された手続を行う他プロセッサ側の処理は、様々なＲＰＣ要求を扱うサーバータスクが代替して実行する。
文献１の技術は、ＲＰＣのような非周期でイベント駆動型の処理が、代替タスクによって実行されるケースに適用できないという課題がある。
第２の従来例としての特許文献２に記載の発明は、ユーザーが動的にアプリケーション毎の実行速度を制御可能としている。これは、ノートパソコンのような、機種毎の性能にばらつきがあり、それが一般的にユーザーに許容されているシステムに対して適用することができるが、携帯電話などの組込みシステムでは、設定した性能基準を満たすよう設計されており、ユーザーが実行速度に関与出来ないという課題がある。
【０００４】
この発明は上記の課題を解決するためになされたもので、ＲＰＣで要求するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）単位で電力レベルを設定しておくことで、性能が重視される高速であるが消費電力が大きい処理と、性能が重視されず消費電力が小さい処理とを適宜選択可能として、高性能プロセッサを不必要に高速に動かすことをなくし、省電力を達成することを目的とする。
また更に、設計時にあらかじめ定めた性能基準を満たせる動作速度をＡＰＩに対して設定しておき、細かく速度性能を指定可能とすることで、与えられた処理要求に対して省電力を考慮した適切な性能配分で実行可能にすることを目的する。
【課題を解決するための手段】
【０００５】
この発明に係るマルチプロセッサ・システムは、メイン処理を行う主プロセッサと、この主プロセッサからの依頼を受けて動作する従プロセッサとからなるマルチプロセッサ・システムにおいて、
上記従プロセッサが処理するアプリケーション・プログラミング・インタフェース単位で上記従プロセッサの動作モードを管理する実行モード管理テーブルと、
上記実行モード管理テーブルで管理される従プロセッサの動作モードに対応してこの従プロセッサの動作クロックまたは印加電源電圧を制御規定し、上記主プロセッサからの依頼が無い場合は上記従プロセッサを停止状態に制御規定する電源管理部と、を備えた。
【発明の効果】
【０００６】
この発明によれば、高性能プロセッサの消費電力を最小限に抑えて、必要な性能を生かして、しかも電力を有効利用できる効果がある。
【発明を実施するための最良の形態】
【０００７】
実施の形態１．
図１は高性能プロセッサの消費電力を最小限に抑えた、この発明の実施の形態１におけるマルチプロセッサシステムの構成図である。
図１において、このマルチプロセッサシステムは、メインの処理を行うプロセッサＡ  １とそのメモリＡ  ３と、プロセッサＡからの依頼を受けて起動する従となる他のプロセッサＢ  ２とそのメモリＢ  ４と、プロセッサＢ  ２に入力される動作クロック周波数を制御するクロック制御部５と、プロセッサＢ  ２に入力される電源電圧を制御する電源制御部６とを含む。
メモリＡ  ３には、プロセッサＡ  １で実行されるアプリケーション１０と、アプリケーション１０からプロセッサＢ  ２に対するＲＰＣによるＡＰＩ実行要求を処理するためのＲＰＣ要求処理部１２と、ＲＰＣ対象ＡＰＩの実行モードを管理するＡＰＩ実行モード管理テーブル１４と、ＲＰＣインタフェース定義ファイル２０と、クロック制御部５と電源制御部６を共に制御する電源管理部１５が含まれる。
また、メモリＢ  ４には、プロセッサＢ  ２でプログラムが読み取られて実行され、プロセッサＡ１からのＲＰＣ要求を処理するＲＰＣサーバとなるＲＰＣサーバ機能部１３と、このＲＰＣ対象であるＲＰＣサーバにより動作するアプリケーション・プログラムのインタフェースとなるＡＰＩ  １１とが含まれる。
【０００８】
本実施の形態において、プロセッサＡ  １が主なアプリケーションの実行を担当する。プロセッサＢ  ２は、高速に実行したい特定の処理のアクセラレータとして機能する、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｏｒ  Ｕｎｉｔ）またはＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）、あるいは特定のデバイスを制御する目的を持ったＣＰＵである。
なお、メモリＡ  ３上にあるアプリケーション１０、ＲＰＣ要求処理部１２、電源管理部１５とメモリＢ  ４上にあるＲＰＣサーバ機能部１３とＡＰＩ  １１は、いずれもソフトウェア・プログラムで記述されており、プロセッサＡ  １及びプロセッサＢ  ２がそのプログラム内容を実行して、各部が行う以下の動作機能を持っている。
【０００９】
次に、本実施の形態において、実行に先立ち用意される、上記のＡＰＩ実行モード管理テーブル１４について述べる。図３は、実施の形態１におけるＡＰＩ実行モード管理テーブル１４を生成するためのシステム構成図である。
図３において、ＲＰＣインタフェース定義ファイル２０には、特定のＡＰＩをＲＰＣで呼び出すために必要なインタフェース定義情報に加え、そのＡＰＩの実行モードが記述されている。ＲＰＣインタフェース生成器２１は、ＲＰＣインタフェース定義ファイル２０を参照し、関数パラメーターをＲＰＣメッセージに組み立てるためのＲＰＣクライアントスタブ２２と、ＲＰＣメッセージからパラメーターを取り出して指定のＡＰＩを呼び出すためのＲＰＣサーバースタブ２３と併せて、ＡＰＩとＡＰＩ実行モードの対応付けを管理するデータ構造であるＡＰＩ実行モード管理テーブル１４を生成する。
このＲＰＣインタフェース生成器２１は、上記のＲＰＣ要求処理部１２と同様に、ソフトウェア・プログラムで記述されており、プロセッサＡ  １または独立のプロセッサがそのプログラム内容を実行して、上記の機能を持っている。
【００１０】
ＲＰＣは、呼出し側と実行側の各々のプロセッサにおいて呼び出される特定のＡＰＩに対して、呼出しパラメーターの伝達方法を共通化しておくことで実現される。そのためには、ＲＰＣ対象ＡＰＩの定義情報をファイルに記述しておき、それをもとに呼出し側と受け側のパラメータ変換処理を実装したＲＰＣスタブを、それぞれ自動的に生成するのが一般的である。
本方式において、ＡＰＩ実行モードは、ＲＰＣ対象となるすべてのＡＰＩに付随する情報であるため、上記のＲＰＣスタブの自動生成処理の一環としてＡＰＩ実行モード管理テーブルを生成させる。これは、対象ＡＰＩを一元管理することにより、記述ミスなどにより発生する矛盾を防止することを目的としている。
ＲＰＣという手段で実行されるＡＰＩは、代理タスクで処理されるという特性から、速度性能を適切に割り当てるよう動作モードを制御する手段に工夫が必要になる。従って、ＲＰＣの仕組みの中に省電力制御を適切に組み込むことが重要である。
ＲＰＣインタフェース定義ファイルの中には、通常のＡＰＩの定義に、ＡＰＩ実行モードをあらわす識別子を付加して記述しておく。ＲＰＣインタフェース生成器が、各々のＡＰＩ定義を解釈しＲＰＣスタブを生成する際に、呼出し側と実行側が同一のＡＰＩであることを識別するために、ＡＰＩに一意の番号または識別子が割り当てられる。ＲＰＣインタフェース生成器は、このＡＰＩの番号または識別子と、動作モードを表す識別子の組を抽出し、ＡＰＩ実行モード管理テーブルとして生成する。
【００１１】
次に動作について図２を用いて説明する。
図２は、プロセッサＡ  １で動作するアプリケーション１０が、プロセッサＢ  ２が持っているＡＰＩ  １１を、ＲＰＣによって実行する処理ステップを表している。
まず、ステップＳ１で、アプリケーションがプロセッサＢのＡＰＩに対する実行要求を発行する。実際には、アプリケーション１０が、ＡＰＩ  １１と同じインタフェースを持つＲＰＣクライアントスタブ２２を呼び出すことになり、ＲＰＣクライアントスタブの内部で、関数パラメーター情報をメッセージパケットにセットする。このメッセージパケットは、ＲＰＣメッセージと呼ばれ、プロセッサＢ  ２のＲＰＣサーバ機能部１３がプロセッサＢ  ２により実行されるＲＰＣサーバがＡＰＩ  １１を実行するために必要な情報が格納される。ＲＰＣクライアントスタブで組み立てられたＲＰＣメッセージは、ＲＰＣ要求処理部１２に渡される。
管理テーブル参照ステップであるステップＳ２で、ＲＰＣ要求処理部１２において、要求されたＡＰＩに対応するＡＰＩ実行モードを、ＡＰＩ実行モード管理テーブル１４を検索して取得する。ＡＰＩ実行モードとは、ＡＰＩ  １１をプロセッサＢ  ２で実行する際のプロセッサＢの状態を指定するための識別子である。例えば、プロセッサＢの動作クロックを低速、中速、高速の３段階で管理するとき、それぞれのクロックに対応するＡＰＩ実行モードをＳＬＯＷ、ＭＩＤＤＬＥ、ＨＩＧＨとして表現する。
【００１２】
ステップＳ３では、ステップＳ２でＲＰＣ要求処理部１２が取得したＡＰＩ実行モードを、電源管理部１５に伝える。電源管理部１５では、ＡＰＩ実行モードに対応するプロセッサＢの動作クロック、及びその動作クロックで動くために必要な電源電圧を管理している。一般に、動作クロックが低ければそのクロックで動作させるのに必要な電圧を低く設定することが可能となり、消費電力をより抑えることが可能である。そして電源管理ステップであるＳ４において電源管理部１５からの指示に基いてクロック制御部５で制御されるプロセッサＢ  ２の動作クロックを変更する。また、併せて電源制御部６から供給されるプロセッサＢ  ２の電源電圧を変更する。
ステップＳ４では同時に、プロセッサＡ側からプロセッサＢ  ２に対して割り込み等の手段を用いて動作の開始を要求する。プロセッサＢ  ２はこの動作要求がなければ、実行を停止して電力消費を軽減するスリープ状態に遷移している。
【００１３】
プロセッサＢ  ２側においてステップＳ１０では、ステップＳ４におけるプロセッサＡからの制御により、プロセッサＢ  ２はスリープ状態が解除され、プログラムの実行が再開される。ここで、ＲＰＣサーバは、プロセッサＡ  １からのプロセッサ間通信によってＲＰＣメッセージが送信されるのを待っている状態となる。
ステップＳ５で、ステップＳ１で組み立てたＲＰＣメッセージを、プロセッサ間通信によりプロセッサＢ  ２が実行するＲＰＣサーバに対して転送する。ここで、ＡＰＩがブロッキングコールであれば、プロセッサＢ  ２でＡＰＩが実行された結果が送信されるのを待つが、ノンブロッキングコールであれば、そこでＡＰＩ実行要求は完了したことになり、アプリケーションに制御が戻る。
ステップＳ１１では、ステップＳ５におけるプロセッサ間通信により送信されたＲＰＣメッセージを、ＲＰＣサーバが受信する。プロセッサＢがＲＰＣサーバ機能部１３を実行した結果であるＲＰＣサーバは、ＲＰＣメッセージの情報から、対象ＡＰＩを識別し、それに対応するＲＰＣサーバスタブを、ＲＰＣメッセージを与えて呼び出す。ＲＰＣサーバスタブでは、ステップＳ１で組み立てられたＲＰＣメッセージを分解し、関数パラメータを取り出す。そして、そのパラメータを伴い要求されたＡＰＩを実行する。このとき、プロセッサＢ  ２は、ステップＳ３で設定した動作クロックおよび電源電圧で要求された動作単位の対象ＡＰＩを実行する。そして単位となる動作が終ると、次の動作指定があるまで以下に示すＳ１２を経てＳ１３の状態となる。
【００１４】
ステップＳ１２は、ＡＰＩがブロッキングコールの場合には、ＲＰＣサーバからプロセッサ間通信メッセージとして、ＡＰＩの実行結果をステップＳ５で待ち状態となっているＲＰＣ要求処理部１２に対してメッセージ送信する。またノンブロッキングコールの場合には何もしない。
ステップＳ６では、ブロッキングコールの場合にステップＳ５でＡＰＩ実行結果待ち状態となっているとき、ステップＳ１２においてプロセッサ間通信メッセージで送信された実行結果を、ＲＰＣ要求処理部１２が受信し、アプリケーション１０に結果とともに制御が戻る。
ステップＳ１３は、プロセッサＢ  ２において、ＡＰＩ  １１実行後、次のＡＰＩ実行要求が来るまでの間は、消費電力を削減するために自身の動作を停止するスリープ状態に遷移する。
こうしてＳ１０ないしＳ１２の間はＡＰＩ単位で動作状態となり、例えば低、中、高速等のＡＰＩ実行モードに対応するクロック、電源電圧でプロセッサＢ  ２が動作し、動作要求が来ない間はスリープ状態になる。
【００１５】
本発明の効果としては、速度性能が要求されるある特定の処理のアクセラレータとしての用途に加え、ある特定のデバイスを制御する用途として、メインのプロセッサの他にサブプロセッサを搭載するシステムにおいて、サブプロセッサ上の処理を、ＡＰＩという細かな単位で適切な性能で実行することが出来る。即ちメインのプロセッサの動作状態に関わらず、サブプロセッサ側の消費電力を必要最小限に抑えるシステムを構築することが可能となる。
近年、プロセッサの性能は向上し、それに伴い消費電力も大きくなってきているが、全ての場合においてその処理性能が必要とは限らない。例えば、携帯端末等のバッテリー持続時間が重視される組込みシステムにおいては、動画再生やＪａｖａ（登録商標）の実行などの処理では、それを実行する際の速度性能が重視されるが、デバイス制御や状態をポーリングする処理などにおける速度性能は重視されないので、できる限り消費電力を低く抑えたい。このような要求に対し、本実施の形態を適用することにより、サブの高性能プロセッサを必要最小限の消費電力で有効に活用ができる。
【００１６】
実施の形態２．
先の実施の形態では、プロセッサＡからプロセッサＢの動作クロックと電源電圧を制御する場合を説明したが、プロセッサＢが自身でモードを管理するようにしてもよい。本実施の形態は自身で管理する場合であり、図４はプロセッサＢが自分の動作クロックと電源電圧を制御可能な構成を示す図である。図４において図１の構成と異なる部分は、プロセッサＢのメモリＢ  ４ｂ上にＡＰＩ実行モード管理テーブル１４と電源管理部１５が含まれる。これらのＡＰＩ実行モード管理テーブル１４と電源管理部１５の機能は、実施の形態１のそれらと同等である。
【００１７】
次に図４の構成システムについて、その動作を図５に基いて説明する。
実施の形態１との相違点は、プロセッサＡ  １で実行していた図１ステップＳ２のＡＰＩ実行モードを自身が管理するＡＰＩ実行モード管理テーブル１４より取得する処理と、図１ステップＳ３の電源管理部１５からプロセッサＢの動作モードを変更する処理を、プロセッサＢ  ２で実行するように変更し、更にＡＰＩ実行終了後、プロセッサＢ  ２の動作モードを元に戻す処理を追加している。
プロセッサＡ  １側の最初の処理は、実施の形態１と同様である。即ち図２のＳ１相当のＳ２０と、同じくＳ４、Ｓ５相当のＳ２１、Ｓ２２でプロセッサＢ  ２に動作要求し、またＲＰＣメッセージを送信する。なお、以下の処理ステップにおいても、実施の形態１と同様の処理ステップは、括弧内に実施の形態１の対応ステップを示している。
これを受けてプロセッサＢ  ２では、ステップＳ３１で、ステップＳ２２においてプロセッサ間通信により送信されたＲＰＣメッセージを、ＲＰＣサーバ機能部１３が受信する。これによりＲＰＣサーバは、ＲＰＣメッセージの情報からパラメータを取り出して対象ＡＰＩを識別する。なお括弧内のＳ１０等は、図２の動作と同等の動作を示している。
ステップＳ３２で、ステップＳ３１で識別した対象ＡＰＩに対応する実行モードを、ＡＰＩ実行モード管理テーブル１４を検索して取得する。
【００１８】
ステップＳ３３で、ステップＳ３２で取得したＡＰＩ実行モードを、電源管理部１５に伝える。なお、このときプロセッサＢ  ２は、システムで決められた標準の動作クロックおよび電源電圧で動作している。電源管理手段では、ＡＰＩ実行モードに対応するプロセッサＢの動作クロック、およびその動作クロックで動くために必要な電源電圧を管理している。
電源管理部１５から、クロック制御部５で供給されるプロセッサＢ  ２の動作クロックを変更する。また、併せて電源制御部６経由で供給されるプロセッサＢ  ２の電源電圧を変更する。
ステップＳ３４で、ＲＰＣサーバは、ＡＰＩ  １１に対応するＲＰＣサーバスタブを、ＲＰＣメッセージを与えて呼び出す。ＲＰＣサーバスタブでは、ＲＰＣメッセージを分解し、関数パラメーターを取り出す。そして、そのパラメーターを伴い要求されたＡＰＩを実行する。このとき、プロセッサＢ  ２は、直前で設定した動作クロックおよび電源電圧で対象ＡＰＩを実行する。
ステップＳ３５は、ＡＰＩ  １１がブロッキングコールの場合には、ＲＰＣサーバからのＡＰＩの実行結果を、プロセッサ間通信メッセージとして、ステップＳ２２で待ち状態となっているＲＰＣ要求処理部１２に対してメッセージ送信する。ノンブロッキングコールの場合にはなにもしない。
ステップＳ３６では、ステップＳ３３で変更したプロセッサＢ  ２の動作クロックと電源電圧を、変更前の状態であるシステムで定められた標準の動作クロックおよび電源電圧に戻す。
【００１９】
本実施の形態では、実施の形態１で述べた効果に加え、ＡＰＩ実行の前後に入るＲＰＣに関する処理がＡＰＩ実行時の動作クロックに影響されないため、性能および省電力の観点から、より正確な制御が可能となる。
また、サブとなるプロセッサＢ  ２が複数のメイン処理プロセッサ（プロセッサＡ相当）から指示されて動作する場合に、これらの複数の指示中で最も高速の処理を要求されるクロックと電源電圧をプロセッサＢ側で設定できる。
【００２０】
実施の形態３．
先の実施の形態では、プロセッサＢがプロセッサＡからの指示に基いて自身の動作クロックと電源電圧を制御する場合を説明したが、プロセッサＡがで実行モードの管理をし、その実行モードの指定によりプロセッサＢが自身のクロックと電圧を管理するようにしてもよい。
本実施の形態はそのような分担管理する場合であり、図６は具体的なシステムの構成の例を示す図である。即ち、プロセッサＡ  １のメモリＡ  ３ｃ上にＡＰＩ実行モード管理テーブル１４が含まれ、プロセッサＢ  ２のメモリＢ  ４ｃ上に電源管理部１５が含まれる。
【００２１】
次に図６の構成システムについて、その動作を図７に基いて説明する。
実施の形態２との相違点は、プロセッサＢ  ２で実行していた図５ステップＳ３２のＡＰＩ実行モードをＡＰＩ実行モード管理テーブル１４より取得する処理を、実施の形態１と同様にプロセッサＡ  １で実行するよう変更し、更にプロセッサＡからプロセッサＢに対してプロセッサ間通信によって転送するＲＰＣメッセージにＡＰＩ実行モードを追加し、プロセッサＢ  ２のＲＰＣサーバ機能部１３から電源管理部１５に実行モードの変更を行う処理としている。
ステップＳ４０で、アプリケーションがプロセッサＢのＡＰＩに対する実行要求を発行し、ＲＰＣクライアントスタブが実行される。ＲＰＣクライアントスタブでは、関数パラメータ情報をＲＰＣメッセージとして組み立て、それをＲＰＣ要求処理部１２に渡す。
ステップＳ４１で、ＲＰＣ要求処理部１２において、要求されたＡＰＩに対応するＡＰＩ実行モードを、ＡＰＩ実行モード管理テーブル１４を検索して取得する。そして、取得したＡＰＩ実行モードを、ステップＳ４１で用意したＲＰＣメッセージに追加する。
【００２２】
ステップＳ５１で、  プロセッサ間通信により送信されたＲＰＣメッセージを、ＲＰＣサーバ機能部１３が受信する。そして、ＲＰＣメッセージの情報から、ステップＳ４１で追加されたＡＰＩ実行モードを取り出す。また、ＲＰＣメッセージの情報から、対象ＡＰＩを識別する。
ステップＳ５２で、上記のステップＳ５１で取得したＡＰＩ実行モードを電源管理部１５に伝える。なお、このときプロセッサＢ  ２は、システムで決められた標準の動作クロックおよび電源電圧で動作している。電源管理部１５では、ＡＰＩ実行モードに対応するプロセッサＢ  ２の動作クロック、およびその動作クロックで動くために必要な電源電圧を管理している。電源管理部１５から、クロック制御部５で供給されるプロセッサＢの動作クロックを変更する。また、併せて電源制御部６で供給されるプロセッサＢの電源電圧を変更する。
ステップＳ５３では、ステップＳ５１で識別した対象ＡＰＩに対応するＲＰＣサーバスタブを、ＲＰＣメッセージを与えて呼び出す。ＲＰＣサーバスタブでは、ステップＳ４０で組み立てられたＲＰＣメッセージを分解し、関数パラメーターを取り出す。そして、そのパラメーターを伴い要求されたＡＰＩを実行する。このとき、プロセッサＢは、ステップＳ５２で設定した動作クロックおよび電源電圧で対象ＡＰＩを実行する。
【００２３】
ステップＳ５４以降は、実施の形態２で示した動作と同様である。
本実施の形態においても、実施の形態２で示した構成と同等の効果を得ることができる。
【００２４】
上記各実施の形態では、各要素はハードウェアで構成されるか、または専用の要素で構成されるとして説明したが、これらの要素を汎用の計算機で構成し、上記で記述した機能をソフトウェアのプログラムで記述して、上記の処理動作を示すフロー図で示す方法で実現してもよい。またそれらのフローで示される方法を記述したプログラムを計算機読み取り可能な記録媒体に記録して、汎用計算機で読み出してメモリに展開し、機能を得るようにしてもよい。
【図面の簡単な説明】
【００２５】
【図１】この発明の実施の形態１におけるマルチプロセッサシステムの構成図である。
【図２】実施の形態１におけるアプリケーションを実行する処理動作を示すフロー図である。
【図３】実施の形態１におけるＡＰＩ実行モード管理テーブルを生成するためのシステム構成図である。
【図４】この発明の実施の形態２におけるマルチプロセッサシステムの構成図である。
【図５】実施の形態２におけるアプリケーションを実行する処理動作を示すフロー図である。
【図６】この発明の実施の形態３におけるマルチプロセッサシステムの構成図である。
【図７】実施の形態３におけるアプリケーションを実行する処理動作を示すフロー図である。
【符号の説明】
【００２６】
１  プロセッサＡ、２  プロセッサＢ、３，３ｂ，３ｃ  メモリＡ、４，４ｂ，４ｃ  メモリＢ、５  クロック制御部、６  電源制御部、１０  アプリケーション、１１  ＡＰＩ、１２  ＲＰＣ要求処理部、１３  ＲＰＣサーバ機能部、１４  ＡＰＩ実行モード管理テーブル、１５  電源管理部、２０  ＲＰＣインタフェース定義ファイル、２１  ＲＰＣインタフェース生成器、Ｓ２  管理テーブル参照ステップ、Ｓ４  電源管理ステップ。
【図１】
2006163970.tif 000003
【図２】
2006163970.tif 000004
【図３】
2006163970.tif 000005
【図４】
2006163970.tif 000006
【図５】
2006163970.tif 000007
【図６】
2006163970.tif 000008
【図７】
2006163970.tif 000009