(57)【要約】【課題】資源間の結合強度を解析し、結合強度に基づいて複数のプロセッサコアへの個々の資源の配置方法を決定し、資源配分を行う。【解決手段】アプリケーションのタスクや共通関数、共通変数などの資源を複数のプロセッサコアに配置する際に、資源間の結合強度を求め、求めた資源間の結合強度に応じて割り付けを行う。これにより、ユーザが任意に割り当てを行うよりも、より最適な割り当てが可能となる。結果として、アプリケーションのパフォーマンスを向上させることが可能となる。【選択図】図４
2011141703.tif 000002
【特許請求の範囲】
【請求項１】
一度アプリケーションプログラムを実行させ、動作結果としてトレース情報を出力するデバッガと、
前記アプリケーションのタスク、共通関数、共通変数を資源として扱い、前記トレース情報から資源間のデータアクセス回数を算出し、前記算出されたデータアクセス回数を資源間の結合強度として扱い、資源間の結合強度に応じて、マルチプロセッサのコアへの資源配分を行うホストＰＣと
を具備する
資源配置システム。
【請求項２】
請求項１に記載の資源配置システムであって、
前記ホストＰＣは、資源間のデータアクセス回数が閾値より多い資源の各々を同じコアに配置し、資源間のデータアクセス回数が閾値以下である資源の各々を別々のコアに配置し、データアクセス回数の増大によるコア間のオーバーヘッドの発生を抑制する
資源配置システム。
【請求項３】
請求項２に記載の資源配置システムであって、
前記ホストＰＣは、全てのデータアクセス回数の平均値を算出し、データアクセス回数が平均値以下の資源間の結合を切り離して部分集合に分け、部分集合毎に、マルチプロセッサのコアへの資源配分を行う
資源配置システム。
【請求項４】
請求項３に記載の資源配置システムであって、
前記ホストＰＣは、最も資源が少ない部分集合から順に、当該部分集合の中で、データアクセス回数が最大となる資源間の結合を復元する
資源配置システム。
【請求項５】
請求項１乃至４のいずれか一項に記載の資源配置システムであって、
前記ホストＰＣは、タスクをＲＴＯＳ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）資源として扱い、共通関数及び共通変数を共通資源として扱い、前記トレース情報から、ＲＴＯＳ資源からＲＴＯＳ資源への状態遷移と、ＲＴＯＳ資源から共通資源へのデータアクセスと、を解析し、資源間のデータアクセス回数を算出する
資源配置システム。
【請求項６】
請求項１乃至５のいずれか一項に記載の資源配置システムで、デバッガ及びホストＰＣのうち少なくとも一方として使用されるコンピュータ。
【請求項７】
一度アプリケーションプログラムを実行させ、動作結果としてトレース情報を出力することと、
前記アプリケーションのタスク、共通関数、共通変数を資源として扱い、前記トレース情報から資源間のデータアクセス回数を算出し、前記前記算出されたデータアクセス回数を資源間の結合強度として扱い、資源間の結合強度に応じて、マルチプロセッサのコアへの資源配分を行うことと
を含む
資源配置方法。
【請求項８】
請求項７に記載の資源配置方法であって、
資源間のデータアクセス回数が閾値より多い資源の各々を同じコアに配置し、資源間のデータアクセス回数が閾値以下である資源の各々を別々のコアに配置し、データアクセス回数の増大によるコア間のオーバーヘッドの発生を抑制すること
を更に含む
資源配置方法。
【請求項９】
請求項８に記載の資源配置方法であって、
全てのデータアクセス回数の平均値を算出し、データアクセス回数が平均値以下の資源間の結合を切り離して部分集合に分け、部分集合毎に、マルチプロセッサのコアへの資源配分を行うこと
を更に含む
資源配置方法。
【請求項１０】
請求項９に記載の資源配置方法であって、
最も資源が少ない部分集合から順に、当該部分集合の中で、データアクセス回数が最大となる資源間の結合を復元すること
を更に含む
資源配置方法。
【請求項１１】
請求項７乃至１０のいずれか一項に記載の資源配置方法であって、
タスクをＲＴＯＳ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）資源として扱い、共通関数及び共通変数を共通資源として扱い、前記トレース情報から、ＲＴＯＳ資源からＲＴＯＳ資源への状態遷移と、ＲＴＯＳ資源から共通資源へのデータアクセスと、を解析し、資源間のデータアクセス回数を算出すること
を更に含む
資源配置方法。
【請求項１２】
一度アプリケーションプログラムを実行させ、動作結果としてトレース情報を出力するステップと、
前記アプリケーションのタスク、共通関数、共通変数を資源として扱い、前記トレース情報から資源間のデータアクセス回数を算出し、前記前記算出されたデータアクセス回数を資源間の結合強度として扱い、資源間の結合強度に応じて、マルチプロセッサのコアへの資源配分を行うステップと
をコンピュータに実行させるための
資源配置用プログラム。
【請求項１３】
請求項１２に記載の資源配置用プログラムであって、
資源間のデータアクセス回数が閾値より多い資源の各々を同じコアに配置し、資源間のデータアクセス回数が閾値以下である資源の各々を別々のコアに配置し、データアクセス回数の増大によるコア間のオーバーヘッドの発生を抑制するステップ
を更にコンピュータに実行させるための
資源配置用プログラム。
【請求項１４】
請求項１３に記載の資源配置用プログラムであって、
全てのデータアクセス回数の平均値を算出し、データアクセス回数が平均値以下の資源間の結合を切り離して部分集合に分け、部分集合毎に、マルチプロセッサのコアへの資源配分を行うステップ
を更にコンピュータに実行させるための
資源配置用プログラム。
【請求項１５】
請求項１４に記載の資源配置用プログラムであって、
最も資源が少ない部分集合から順に、当該部分集合の中で、データアクセス回数が最大となる資源間の結合を復元するステップ
を更にコンピュータに実行させるための
資源配置用プログラム。
【請求項１６】
請求項１２乃至１５のいずれか一項に記載の資源配置用プログラムであって、
タスクをＲＴＯＳ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）資源として扱い、共通関数及び共通変数を共通資源として扱い、前記トレース情報から、ＲＴＯＳ資源からＲＴＯＳ資源への状態遷移と、ＲＴＯＳ資源から共通資源へのデータアクセスと、を解析し、資源間のデータアクセス回数を算出するステップ
を更にコンピュータに実行させるための
資源配置用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、資源配置システムに関し、特に静的なシステムにおける資源（リソース）の配置を行う資源配置システムに関する。
【背景技術】
【０００２】
従来、マルチプロセッサ対応ＲＴＯＳ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）のような複数のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）コアとメモリを持つシステムでは、図１に示すように、複数のＣＰＵコアの各々に対するタスクの配置を、ユーザが決定する。図１では、ＣＰＵコアとして、コア１、コア２を記載している。
【０００３】
このとき、メモリは、図２に示すように、複数のＣＰＵコアの各々に配置されるタスクの基となるソースファイルと、ユーザにより決定されたタスクの配置方法を示すＲＴＯＳ用情報定義ファイルを保持している。
【０００４】
例えば、特開２００６−００３９７２号公報（特許文献１）に記載の従来技術では、性能を低下させるようなコンピュータ資源の消費を行わずに、ノード間メモリアクセスを削減する。
【０００５】
従来技術では、ＣＰＵコアとメモリが複数存在するｃｃＮＵＭＡ（Ｃａｃｈｅ  Ｃｏｈｅｒｅｎｔ  Ｎｏｎ−Ｕｎｉｆｏｒｍ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）アーキテクチャを想定している。ｃｃＮＵＭＡは、マルチプロセッサ・コンピュータ・システムのためのＮＵＭＡ（Ｎｏｎ−Ｕｎｉｆｏｒｍ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）の変形である。ＮＵＭＡシステムは、複数のサーバ・ビルディング・ブロックで構成されている。各ブロックには、プロセッサ、メモリ、入出力コンポーネントが含まれている。ｃｃＮＵＭＡシステムでは、ＣＰＵコアとメモリは、ノードの単位で分割する。分割したノードに、プログラムに含まれる１以上のプロセス（タスク）の各プロセスを割り当てる。
【０００６】
例として、あるプロセスＡが存在し、プロセスＡを実行する予定となっているノード１があるとする。また、プロセスＡにアクセスする回数が最も高いノード２があるとする。
【０００７】
従来技術では、以下の３つの手段を提案している。
（１）上記例のノード１とノード２を検出する。
（２）検出したノード１とノード２が同じでないかを判断する。
（３）検出したノード１とノード２が同じでない場合、プロセスＡの割り当てをノード２に変更する。
【０００８】
従来技術では、動的にプロセスの割り当てを変更するという考えのもと成り立っている。しかし、静的にプロセスの割り当てを行うシステムも存在する。静的にプロセスの割り当てを行う場合は、動的とは異なり、プロセスの割り当てを行うための判断指標がない。判断指標がないため、ユーザがアプリケーション（アプリケーションプログラム）の構成を理解し、プロセスの割り当てを決定しなければならない。しかし、アプリケーションの構成を知らないユーザが配置を決定する場合は、不適切な配置をしてしまう恐れがある。
【０００９】
このように、静的なシステムにおける資源（リソース）の配置を行う際には、以下のような２つの問題点があった。
【００１０】
（１）システムの膨大化
システムが膨大になるにつれて、ユーザ・アプリケーションで使用するタスク数が増加する。タスク間の結合の関連が難しいため、コアへの資源の配置方法の判断が難しい。
【００１１】
（２）ハードウェア技術の向上
性能や低消費電力の技術化が進み、現在マルチプロセッサのコア数が増加している。つまり、どのタスクをどのコアへ配置すれば良いのかの判断が難しい。
【００１２】
上記の２つの問題点のため、マルチプロセッサのコアへの資源の配置方法の決定は難しくなる。
【００１３】
関連する技術として、特開２００６−００３９７２号公報（特許文献１）にプロセス配置装置、プロセス配置方法及びプロセス配置プログラムが開示されている。この関連技術では、プロセス配置装置は、プログラムに含まれる１以上のプロセスのうちの各プロセスが、ｃｃＮＵＭＡアーキテクチャの何れかのノードに属するＣＰＵと何れかのノードに属するメモリを用いて実行される方式に適用される。このプロセス配置装置は、ノード検出手段と、ノード一致判断手段と、ＣＰＵ割当変更手段を備える。ノード検出手段は、各プロセス毎に、該プロセスを実行するＣＰＵが属するノードである第１ノード及び所定時間内に該ＣＰＵがアクセスする回数が最も高いメモリが属するノードである第２ノードを検出する。ノード一致判断手段は、各プロセス毎に、第１ノードと第２ノードが一致するか否かを判断する。ＣＰＵ割当変更手段は、各プロセス毎に、第１ノードと第２ノードとが一致しない場合に、該プロセスを実行するＣＰＵを、第２ノードに属するＣＰＵに変更する。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開２００６−００３９７２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１５】
本発明は、マルチプロセッサ対応ＲＴＯＳの分野に関するものであり、従来技術の課題であった資源の配置方法をユーザに静的に定義させる方法に対して、資源間の結合強度を解析し、結合強度に基づいて複数のプロセッサコアへの個々の資源の配置方法を決定し、資源配分を行うという工夫を行うことで解決することを図る。
【課題を解決するための手段】
【００１６】
本発明の資源配置システムは、一度アプリケーションプログラムを実行させ、動作結果としてトレース情報を出力するデバッガと、アプリケーションのタスク、共通関数、共通変数を資源として扱い、トレース情報から資源間のデータアクセス回数を算出し、前記算出されたデータアクセス回数を資源間の結合強度として扱い、資源間の結合強度に応じて、マルチプロセッサのコアへの資源配分を行うホストＰＣ（パソコン）とを具備する。
【００１７】
本発明の資源配置方法では、一度アプリケーションプログラムを実行させ、動作結果としてトレース情報を出力する。次に、アプリケーションのタスク、共通関数、共通変数を資源として扱い、トレース情報から資源間のデータアクセス回数を算出し、前記算出されたデータアクセス回数を資源間の結合強度として扱い、資源間の結合強度に応じて、マルチプロセッサのコアへの資源配分を行う。
【００１８】
本発明の資源配置用プログラムは、一度アプリケーションプログラムを実行させ、動作結果としてトレース情報を出力するステップと、アプリケーションのタスク、共通関数、共通変数を資源として扱い、トレース情報から資源間のデータアクセス回数を算出し、前記算出されたデータアクセス回数を資源間の結合強度として扱い、資源間の結合強度に応じて、マルチプロセッサのコアへの資源配分を行うステップとをコンピュータに実行させるためのプログラムである。なお、本発明の資源配置用プログラムは、記憶装置又は記憶媒体に格納可能である。
【発明の効果】
【００１９】
アプリケーションのタスクや共通関数、共通変数などの資源を複数のプロセッサコアに配置する際に、資源間の結合強度を求め、求めた資源間の結合強度に応じて割り付けを行う。これにより、ユーザが任意に割り当てを行うよりも、より最適な割り当てが可能となる。結果として、アプリケーションのパフォーマンスを向上させることが可能となる。
【図面の簡単な説明】
【００２０】
【図１】静的なシステムにおける資源の配置図である。
【図２】ＲＴＯＳを使用したアプリケーション開発の際における資源の配置方法の概要図である。
【図３】本発明の実施例の図である。
【図４】本発明の構成及び処理の流れの図である。
【図５】本発明の処理の流れを示すフローチャートである。
【図６】資源間のデータアクセス回数解析例の図である。
【図７】資源間の結合解析結果の図である。
【図８】資源の分割アルゴリズムの説明の図である。
【図９】資源の分割アルゴリズムの説明の図である。
【図１０】資源の分割アルゴリズムの説明の図である。
【図１１】資源の分割アルゴリズムの説明の図である。
【図１２】分割結果の反映の図である。
【発明を実施するための形態】
【００２１】
以下に、本発明の実施形態について添付図面を参照して説明する。
【００２２】
＜用語の定義＞
まず、本発明では、資源（リソース）という言葉を下記のように定義する。
・ＲＴＯＳ資源  ＝  タスク
・共通資源  ＝  共通関数や共通変数
【００２３】
また、資源間の結合強度の重みを下記のように定義する。
・結合強度  ＝  ある資源から他の資源へのデータアクセス回数
【００２４】
＜概要＞
資源間の結合強度を求め、求めた結合強度の解析を行い、ＣＰＵへの割り当てを行う手法が本発明の構成である。具体的な資源間の結合強度の求めかた、及びＣＰＵへの割り当て手法に関しては下記に記述する。
【００２５】
資源間の結合強度をデータアクセス回数と定義した理由は、性能という点に着目し、性能の妨げになるオーバーヘッドを考慮したためである。マルチプロセッサにおいて、コアをまたぐデータアクセスは、オーバーヘッドが発生する。つまり、コアをまたぐデータアクセス回数が多くなればなるほど、そのオーバーヘッドは大きくなる。本発明においては、資源間のデータアクセス回数が他の資源間と比較して相対的に多いものを同じコアに配置し、資源間のデータアクセス回数が他の資源間と比較して相対的に少ないものを別々のコアに配置することで、コア間のオーバーヘッドの短縮を図る。例えば、資源間のデータアクセス回数の平均値（又は中間値）を求め、資源間のデータアクセス回数が平均値（又は中間値）より多い場合、これらの資源を同じコアに配置し、資源間のデータアクセス回数が平均値（又は中間値）以下の場合、これらの資源を別々のコアに配置する。ここでは、平均値（又は中間値）が閾値となる。なお、データアクセス回数の大小については、予め設定された所定の回数を閾値として判断するようにしても良い。或いは、資源間のデータアクセス回数が最小のものから少ない順に、所定の数だけ、別々のコアに配置するようにしても良い。このように、静的に資源の配置を決定するシステムで、資源間のデータアクセス回数を解析し、コア間のオーバーヘッドが少ない資源の配置方法を決定し、資源配分を行う手法が本発明である。
【００２６】
＜実施例＞
ここで、実施例として、図３のようなアプリケーションをユーザが作成した場合を考える。図３のアプリケーションの資源の構成は、下記の表１に示すようになっている。
【００２７】
【表１】
2011141703.tif 000003
【００２８】
本発明では、静的に資源のマルチプロセッサへ配置するシステムにおいて、上記の資源の配置方法をユーザ任せにしない。
【００２９】
図４は、コアへの資源の配置を決定する手順の一連の流れを示している。
なお、図４に示すように、本発明の資源配置システムは、ホストＰＣ（パソコン）１０と、デバッガ２０を備える。ホストＰＣ１０は、複数のＣＰＵコアとメモリを持つマルチプロセッサ対応ＲＴＯＳの計算機である。ホストＰＣ１０は、少なくとも、コア１、コア２、メモリを備えるものとする。メモリは、ユーザ・アプリケーションのソースファイルや実行ファイル、ＲＴＯＳ用情報定義ファイルを保持する。実行ファイルの内容は、図３に示す通りである。デバッガ２０は、シミュレータ２１を備える。シミュレータ２１は、ＣＰＵ２２を備える。ＣＰＵ２２は、ユーザ・アプリケーションやＲＴＯＳを実行する。
【００３０】
ここでは、ホストＰＣ１０及びデバッガ２０の例として、ＰＣを想定している。他にも、ホストＰＣ１０及びデバッガ２０の例として、シンクライアント端末／サーバ、ワークステーション、メインフレーム、スーパーコンピュータ等の計算機が考えられる。但し、実際には、これらの例に限定されない。
【００３１】
ホストＰＣ（パソコン）１０とデバッガ２０は、ネットワークを介して接続可能である。ネットワークの例として、インターネット、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ  ＬＡＮ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、バックボーン（Ｂａｃｋｂｏｎｅ）、ケーブルテレビ（ＣＡＴＶ）回線、固定電話網、携帯電話網、ＷｉＭＡＸ（ＩＥＥＥ  ８０２．１６ａ）、３Ｇ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ）、専用線（ｌｅａｓｅ  ｌｉｎｅ）、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ  Ｄａｔａ  Ａｓｓｏｃｉａｔｉｏｎ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、シリアル通信回線、データバス等が考えられる。但し、実際には、これらの例に限定されない。
【００３２】
また、コア１及びコア２の例として、ＣＰＵを想定している。他にも、コア１及びコア２の例として、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）、マイクロコントローラ、或いは、同様の機能を有する半導体集積回路（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ（ＩＣ））等が考えられる。但し、実際には、これらの例に限定されない。
【００３３】
また、メモリの例として、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）やフラッシュメモリ等の半導体記憶装置、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の補助記憶装置、又は、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）やメモリカード等の記憶媒体（メディア）等が考えられる。但し、実際には、これらの例に限定されない。
【００３４】
なお、図４では、ホストＰＣ１０とデバッガ２０は、それぞれ独立した装置として記載しているが、実際には、ホストＰＣ１０とデバッガ２０は、同一の装置でも良い。
【００３５】
図５は、コアへの資源の配置を決定する際の詳細な処理フローを示している。
【００３６】
（１）ステップＳ１
ホストＰＣ１０は、ユーザからの指示に応じて、ユーザ・アプリケーションを作成する。ここでは、コア１又はコア２が、ユーザからの指示に応じて、ユーザ・アプリケーションのソースファイルを作成する。このとき、ユーザは、資源のコアへの配置を考慮する必要はない。
【００３７】
（２）ステップＳ２
ホストＰＣ１０は、実行ファイルを作成する。ここでは、コア１又はコア２が、ユーザ・アプリケーションのソースファイルに基づいて、実行ファイルを作成する。例えば、コア１又はコア２は、コンパイルにより、ユーザ・アプリケーションのソースファイルを、コンピュータ上で実行可能な形式に変換する。ホストＰＣ１０は、実行ファイルをデバッガ２０に提供する。
【００３８】
（３）ステップＳ３
デバッガ２０は、一定期間、ユーザ・アプリケーションを動作させ、動作結果としてトレース情報を出力する。ユーザ・アプリケーションを動作させる手法として、例えば、ユーザが期待するようなテストパターンを組み込んだ動作手法も効果的である。動作させる環境としては、例えば、ターゲットマルチプロセッサをシングルプロセッサと仮定したシミュレータ上で動作させる。ここでは、デバッガ２０は、ホストＰＣ１０から実行ファイルをダウンロードする。シミュレータ２１は、ＣＰＵ２２により、ＲＴＯＳと実行ファイルを実行し、一定期間、ユーザ・アプリケーションを動作させ、動作結果としてトレース情報を出力する。なお、トレース情報を出力するためには、そのトレース情報を出力させるための仕組が必要となる。そのため、トレース情報を出力するための仕組みを、ＲＴＯＳに組み込むようにしても良い。
【００３９】
（４）ステップＳ４
ホストＰＣ１０は、入力されたトレース情報を参照し、資源間のデータアクセスを解析し、データアクセス回数を結合強度として導き出し、解析結果を出力する。ここでは、コア１又はコア２は、トレース情報から資源間のデータアクセス回数を割り出す。また、トレース情報から解析されるデータアクセスは、「ＲＴＯＳ資源からＲＴＯＳ資源への状態遷移」、「ＲＴＯＳ資源から共通資源へのデータアクセス」の２点とする。
【００４０】
（５）ステップＳ５
ホストＰＣ１０は、解析結果に基づいて、資源のコアへの配置方法を決定し、決定した配置方法に従って資源配分を行う。グラフの分割方法に関しては、公知のグラフ理論を使用することで、分割可能である。ここでは、ホストＰＣ１０は、コアへの資源の配置方法が示されたＲＴＯＳ用情報定義ファイルをメモリに記憶する。コア１及びコア２は、ＲＴＯＳ用情報定義ファイルに基づいて、ＲＴＯＳ資源や共通資源を取得する。或いは、ホストＰＣ１０内の資源配置専用のコア（図示せず）が、ＲＴＯＳ用情報定義ファイルに基づいて、コア１及びコア２に、ＲＴＯＳ資源や共通資源を配置するようにしても良い。
【００４１】
図６は、トレース情報からデータアクセス回数を解析する方法の例を示している。
この例では、まずタスク１からタスク２へ状態遷移を行っているので、タスク１とタスク２間のデータアクセスが「１」となる。次に、タスク２から共通資源１へのデータアクセスを行っているので、タスク２と共通資源のデータアクセスが「１」となる。同様に、タスク２からタスク３へ状態遷移を行っているので、タスク２とタスク３間のデータアクセスが「１」となる。このようにして、ある一定期間動作させたトレース情報から、資源間のデータアクセス回数を導き出す。得られたデータアクセス回数を資源間の結合強度として扱う。
【００４２】
次に、得られたデータアクセス回数から資源の配置方法を決定する手法を、以下に示す。
【００４３】
ホストＰＣ１０は、データアクセスの解析結果、資源間のデータアクセス回数が少ない箇所を判断し、その箇所を分割する。分割するアルゴリズムには、公知技術を使用すれば良い。ここでは、分割するアルゴリズムとして、公知の分割統治法の考えを用いる。ホストＰＣ１０は、分割した結果、コア間をまたぐデータアクセスが少ない配置方法を決定することができる。
【００４４】
例として、図７のようなデータアクセスの結果が得られたとする。
図７の矢印に付加されている値は、資源間の結合強度で、データアクセス回数を表している。ホストＰＣ１０は、この情報から分割のアルゴリズムを用いて、資源間の結合を切り離し（カット）し、部分集合に分ける。部分集合に分けた後、部分集合毎に、資源のコアへの配置を決定する。カットする方法として、分割統治法のアルゴリズムを応用する。
【００４５】
［分割統治法］
分割統治法の手順は以下の通りである。
ホストＰＣ１０は、全てのデータアクセス回数の平均値（小数点以下は切り上げ）をとり、その平均値を閾値として定義する。ホストＰＣ１０は、データアクセス回数が閾値以下の資源間の結合をカットする。
【００４６】
図７〜図１２を参照して説明する。
【００４７】
図７の各種矢印は、以下の意味を持つ。
点線矢印：資源間の結合
実線矢印：カットする対象の資源間の結合
【００４８】
ここで、全てのデータアクセス回数の平均値は、
（１＋７＋３＋８＋５＋２＋１０＋６＋１＋２＋６）／１１＝４．６・・・
となる。つまり、閾値は「５」となる。
【００４９】
図８は、データアクセス回数が閾値以下の資源間のカット対象である。
【００５０】
ホストＰＣ１０は、上述した方法で得られた結果に対し、更に次の処理を行う。
【００５１】
まず、ホストＰＣ１０は、次の条件（ａ）、（ｂ）に適合するか否かの判定を行う。
（ａ）マルチプロセッサのコア数よりも部分集合が少ない。
（ｂ）マルチプロセッサのコア数よりも部分集合が多い。
【００５２】
条件（ａ）は、例えば、２つのコアがあるマルチプロセッサにおいて、分割した部分集合が１つしか存在しないような場合である。この問題に対しては、ホストＰＣ１０は、分割統治法で決定した閾値を１増加させ、更にカットを行う。
【００５３】
条件（ｂ）は、例えば、２つのコアがあるマルチプロセッサにおいて、分割した部分集合が３つになった場合である。この問題に対しては、ホストＰＣ１０は、部分集合の中で最も資源が少ない部分集合の中で、カットを行ったデータアクセスのデータアクセス回数が最も大きい値となっている箇所の復元を行う。そうすることで、他の部分集合と結合させる。ホストＰＣ１０は、最も資源が少ない部分集合が複数該当する場合は、その部分集合の中でのデータアクセスの総和（データアクセス回数）が最大のものを選択する。
【００５４】
図９は、図７をカットした結果である。ここでは、部分集合は４つとなる。
２つのコアのマルチプロセッサに配置しようとすると、部分集合数が多いことがわかる。この場合は、上記の条件（ｂ）に当てはまる。そのため、以下の手順を行う。
【００５５】
ホストＰＣ１０は、タスク５が最も資源が少ない部分集合となる。
【００５６】
ホストＰＣ１０は、タスク５の部分集合の中で、最もデータアクセス回数が大きい値を復元する。すなわち、タスク５の部分集合の中で、データアクセス回数が最大となる資源間の結合を復元する。ここでは、ホストＰＣ１０は、図１０に示すように、タスク５とタスク３の結合を復元する。黒色の矢印は、結合の復元を表す。これで、部分集合は３つになる。
【００５７】
次に、少ない部分集合は、共通資源１とタスク１、またはタスク６、共通資源２の部分集合である。ホストＰＣ１０は、両方のデータアクセスの総和を比べると、共通資源１とタスク１の部分集合の総和の方が大きいため、そちらを選択する。
【００５８】
ホストＰＣ１０は、共通資源１とタスク１の部分集合の中で、最もデータアクセス回数が大きい値を復元する。すなわち、共通資源１とタスク１の部分集合の中で、データアクセス回数が最大となる資源間の結合を復元する。ここでは、ホストＰＣ１０は、図１１に示すように、タスク１とタスク６の結合を復元する。これで、部分集合は２つになる。
【００５９】
ホストＰＣ１０は、２つに部分集合を分けることができたので、図１２に示すように、部分集合単位で資源をそれぞれのコアへ配置する。
【００６０】
以上の手順で、ホストＰＣ１０は、資源間のデータアクセス回数が少ない箇所をカットした配置方法を決定できる。
【００６１】
本実施例では、資源間の結合強度の少ない箇所をカットする方法として、平均値を使った分割統治法で説明したが、この方法に限られない。結合強度の少ない箇所を求めていく方法として、グラフ分割理論の様々なアルゴリズムが適応可能である。例えばダイクストラ法などが知られており、この方法でも適用可能である。
【００６２】
なお、本発明における一連の処理は、プログラムで駆動される処理装置等のハードウェアと、そのハードウェアを駆動して所望の処理を実行させるプログラム等のソフトウェアと、そのソフトウェアや各種データを格納する記憶装置によって実現されるようにしても良い。例えば、本発明における一連の処理を資源配置方法とした場合、この資源配置方法をコンピュータに実行させるための資源配置用プログラムを、ホストＰＣ１０が実行することによって、資源配置を行うようにしても良い。
【００６３】
＜問題解決のメカニズム＞
システムが増大化すれば、資源が増加するのは明白である。資源の配置を静的に決定するシステムにおいて、資源をどのように配置すれば良いのか、最大限の性能を引き出せているのかなどを判断し、ユーザは配置を決定しなければならない。
【００６４】
また、近年のプロセッサはコア数を増加させ、性能を向上させる傾向にある。しかし、コア数が増加すればコア間の依存関係など、どのように資源を配置すれば最も性能がよくなるかの考慮しなければならないため、ユーザの判断は難しくなる。
【００６５】
上記の例からわかるように、資源の配置をユーザに決定させるのでなく、資源間の結合強度を解析した結果、分割の判断指標を導き出し、その判断指標から配置を決定することで、資源の配置をユーザが決定する必要がなくなる。
【００６６】
＜まとめ＞
以上のように、本発明の資源配置システムは、資源のマルチプロセッサのコアへの配置を決定する際に使用する判断指標を導き出す。決定する方法として、資源間のデータアクセス回数に着目している。
【００６７】
マルチプロセッサ対応ＲＴＯＳにおいて、静的にコアへの資源の配置方法を決定するシステムでは、ユーザが決定することになるが、その判断は難しい。原因は、システムの増大化、及びプロセッサのコア数の増加のためである。
【００６８】
本発明を用いることで、本来ユーザが決定すべきＲＴＯＳ資源（タスク）や共通資源（共通関数や共通変数）のコアへの配置方法の判断指標を導き出し、その判断指標から資源の配置を決定することができる。まず、ユーザに資源の配置を意識させることなく、アプリケーションを組み、一度アプリケーションを動作させる。動作結果から、資源間のデータアクセス回数を（判断指標として）導き出し、その結果を資源間の結合強度とする。資源間の結合強度の強弱（本発明においては、データアクセス回数の大小）からマルチプロセッサのコアへの資源の配置方法を決定し、資源配分を行う。
【００６９】
以上、本発明の実施形態を詳述してきたが、実際には、上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。
【符号の説明】
【００７０】
１０…  ホストＰＣ
２０…  デバッガ
２１…  シミュレータ
２２…  ＣＰＵ
【図１】
2011141703.tif 000004
【図２】
2011141703.tif 000005
【図３】
2011141703.tif 000006
【図４】
2011141703.tif 000007
【図５】
2011141703.tif 000008
【図６】
2011141703.tif 000009
【図７】
2011141703.tif 000010
【図８】
2011141703.tif 000011
【図９】
2011141703.tif 000012
【図１０】
2011141703.tif 000013
【図１１】
2011141703.tif 000014
【図１２】
2011141703.tif 000015