JPWO2012120655A1 - スケジューリング方法およびスケジューリングシステム - Google Patents

Abstract

ＣＰＵ（＃１）は、アプリケーション（ＡＰ）の起動時に、アプリケーション（ＡＰ）の実行のためのアプリ情報（１１０）をメモリ（１０１）から読み出す。ＣＰＵ（＃１）は、メモリ（１０１）から読み出したアプリケーション（ＡＰ）の実行のためのアプリ情報（１１０）を、ＣＰＵ（＃２）〜ＣＰＵ（＃Ｎ）にブロードキャストする。各ＣＰＵ（＃２）〜ＣＰＵ（＃Ｎ）は、アプリ情報（１１０）に基づいて、アプリケーション（ＡＰ）の実行可否を判定する。各ＣＰＵ（＃２）〜ＣＰＵ（＃Ｎ）は、アプリケーション（ＡＰ）を実行可能な場合、アプリケーション（ＡＰ）が実行できる旨をＣＰＵ（＃１）に通知する。ＣＰＵ（＃１）は、アプリケーション（ＡＰ）が実行できる旨の通知があったＣＰＵに、アプリケーション（ＡＰ）を割り当てる。

Description

本発明は、スケジューリング方法およびスケジューリングシステムに関する。

携帯端末などの組込システムにおいて、複数のコアが搭載されたマルチコアプロセッサやメニーコアプロセッサが適用されるようになっている。マルチコア・メニーコアシステムでは、新たなアプリケーションが起動されると、例えば、スケジューリングを行うプロセッサが、システム内の各プロセッサの負荷情報を収集して割当先を求め、アプリケーションのディスパッチを行う。

関連する先行技術として、アプリケーションのディスパッチを行うまでにかかる時間を算出するものがある。また、情報処理システムにおいて、エージェントシステムにおける処理能力の余剰状態を監視し、該余剰状態が生じたエージェントシステムにジョブを実行させる技術がある。

また、クライアントサーバシステムにおいて、各サーバが、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）負荷、ジョブ優先順位、実行ジョブ数などのそれぞれに重み付けを行って閾値を割り当て、この閾値と負荷情報を比較することにより負荷判断を行う技術がある。また、マスタ計算機が、各計算機の負荷情報の通知を受けて余剰能力を評価し、余剰能力が最も高い計算機を選択してジョブを実行させる技術がある。

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

笠原博徳著 「並列処理技術」コロナ社 １９９１年 Ｐ１５６

しかしながら、従来技術では、マルチコアやメニーコアの組込システムにおけるアプリケーションのスケジューリングにかかる時間が増大してしまうという問題がある。例えば、コア数やコア間の通信時間が増えると、アプリケーションのディスパッチが完了するまでにかかる時間が仕様で定められたディスパッチ周期よりも長くなり、性能ボトルネックとなってしまう場合がある。

本発明は、上述した従来技術による問題点を解消するため、スケジューリングを効率的に行うことができるスケジューリング方法およびスケジューリングシステムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明の一側面によれば、第１アプリケーションの起動時に第１ＣＰＵが前記第１アプリケーションの実行のための第１閾値を取得し、前記第１ＣＰＵが前記第１閾値を第２ＣＰＵに送信し、前記第２ＣＰＵの実行能力が前記第１閾値以上であるときは前記第２ＣＰＵは前記第１ＣＰＵに前記第１アプリケーションを実行できる旨を通知し、前記第２ＣＰＵの実行能力が前記第１閾値よりも小さいときは前記第２ＣＰＵは前記第１ＣＰＵへの通知を行わないスケジューリング方法が提案される。

また、上述した課題を解決し、目的を達成するため、本発明の一側面によれば、第１アプリケーションの実行のための第１閾値を格納するメモリと、前記第１アプリケーションの起動時に前記第１閾値を取得する第１ＣＰＵと、実行能力が前記第１ＣＰＵから供給される前記第１閾値以上であるときは前記第１ＣＰＵに前記第１アプリケーションを実行できる旨を通知し、前記実行能力が前記第１閾値よりも小さいときは前記第１ＣＰＵに通知しない第２ＣＰＵとを含むスケジューリングシステムが提案される。

本発明の一側面によれば、スケジューリングを効率的に行うことができるという効果を奏する。

図１は、実施の形態にかかるスケジューリング方法の一実施例を示す説明図である。 図２は、実施の形態にかかるマルチコアシステムのシステム構成例を示す説明図である。 図３は、アプリケーションテーブルの記憶内容の一例を示す説明図である。 図４は、実施の形態にかかるマスタＣＰＵの機能的構成を示すブロック図である。 図５は、第１の応答通知リストの具体例を示す説明図である。 図６は、第２の応答通知リストの具体例を示す説明図である。 図７は、スレッド負荷情報の具体例を示す説明図である。 図８は、実施の形態にかかるスレーブＣＰＵの機能的構成を示すブロック図である。 図９は、実施の形態にかかるマスタＣＰＵの割当処理手順の一例を示すフローチャートである。 図１０は、実施の形態にかかるスレーブＣＰＵの判定処理手順の一例を示すフローチャートである。

以下に添付図面を参照して、この発明にかかるスケジューリング方法およびスケジューリングシステムの実施の形態を詳細に説明する。本実施の形態において、スケジューリングシステムは、コアが複数搭載されたマルチコアプロセッサを含むマルチコアシステムである。マルチコアプロセッサは、コアが複数搭載されていれば、複数のコアが搭載された単一のプロセッサでもよく、シングルコアのプロセッサが並列されているプロセッサ群でもよい。ただし、本実施の形態では、説明を単純化するため、シングルコアのプロセッサが並列されているプロセッサ群を例に挙げて説明する。

（スケジューリング方法の一実施例）
図１は、実施の形態にかかるスケジューリング方法の一実施例を示す説明図である。図１において、マルチコアシステム１００は、ＣＰＵ＃１〜ＣＰＵ＃Ｎと、メモリ１０１と、を含むスケジューリングシステムである。

ＣＰＵ＃１は、マスタＣＰＵであり、マルチコアシステム１００の全体の制御を司る。ＣＰＵ＃１は、アプリケーションをどのＣＰＵに割り当てるかを制御する。また、ＣＰＵ＃１は、割り当てられたアプリケーションを実行する。ＣＰＵ＃２〜ＣＰＵ＃Ｎは、スレーブＣＰＵであり、割り当てられたアプリケーションを実行する。メモリ１０１は、ＣＰＵ＃１〜ＣＰＵ＃Ｎに共有されるメモリである。

以下、アプリケーションの起動時に実行されるマルチコアシステム１００のスケジューリング処理の一実施例について説明する。

（１）ＣＰＵ＃１は、アプリケーション（図１中、「アプリ」）ＡＰの起動時に、アプリケーションＡＰの実行のためのアプリ情報１１０をメモリ１０１から読み出す。ここで、アプリ情報１１０は、例えば、アプリケーションＡＰに含まれるスレッド数や、アプリケーションＡＰの実行に必要なＣＰＵの実行能力を示す情報である。

（２）ＣＰＵ＃１は、メモリ１０１から読み出したアプリケーションＡＰの実行のためのアプリ情報１１０を、ＣＰＵ＃２〜ＣＰＵ＃Ｎにブロードキャストする。

（３）各ＣＰＵ＃２〜ＣＰＵ＃Ｎは、アプリ情報１１０に基づいて、アプリケーションＡＰの実行可否を判定する。具体的には、例えば、各ＣＰＵ＃２〜ＣＰＵ＃Ｎは、自ＣＰＵの実行能力と、アプリ情報１１０が示すアプリケーションＡＰの実行に必要なＣＰＵの実行能力とを比較して、アプリケーションＡＰの実行可否を判定する。

（４ａ）各ＣＰＵ＃２〜ＣＰＵ＃Ｎは、アプリケーションＡＰを実行可能な場合、アプリケーションＡＰが実行できる旨をＣＰＵ＃１に通知する。具体的には、例えば、各ＣＰＵ＃２〜ＣＰＵ＃Ｎは、自ＣＰＵの実行能力が、アプリケーションＡＰの実行に必要なＣＰＵの実行能力以上の場合、アプリケーションＡＰが実行できる旨をＣＰＵ＃１に通知する。

図１の例では、ＣＰＵ＃２の実行能力がアプリケーションＡＰの実行に必要なＣＰＵの実行能力以上のため、ＣＰＵ＃２が、アプリケーションＡＰが実行できる旨をＣＰＵ＃１に通知している。

（４ｂ）各ＣＰＵ＃２〜ＣＰＵ＃Ｎは、アプリケーションＡＰを実行不能な場合、アプリケーションＡＰの実行可否に関するＣＰＵ＃１への通知を行わない。具体的には、例えば、各ＣＰＵ＃２〜ＣＰＵ＃Ｎは、自ＣＰＵの実行能力が、アプリケーションＡＰの実行に必要なＣＰＵの実行能力よりも小さい場合、アプリケーションＡＰの実行可否に関するＣＰＵ＃１への通知を行わない。

図１の例では、ＣＰＵ＃Ｎの実行能力がアプリケーションＡＰの実行に必要なＣＰＵの実行能力よりも小さいため、ＣＰＵ＃ＮからＣＰＵ＃１へのアプリケーションＡＰの実行可否に関する通知は行われていない（図１中、「非通知」）。

（５）ＣＰＵ＃１は、アプリケーションＡＰが実行できる旨の通知があったＣＰＵ（例えば、ＣＰＵ＃２）に、アプリケーションＡＰを割り当てる。この結果、例えば、割当先のＣＰＵ＃２により、アプリケーションＡＰが実行される。

このように、マルチコアシステム１００によれば、新たに起動されたアプリケーションＡＰの実行可否を各ＣＰＵ＃２〜ＣＰＵ＃Ｎに判定させることができる。これにより、ＣＰＵ＃１が各ＣＰＵ＃２〜ＣＰＵ＃Ｎの実行可否を判定する場合に比べて、スケジューリング時におけるＣＰＵ＃１の負荷を軽減させることができる。また、スケジューリング時に各ＣＰＵ＃２〜ＣＰＵ＃Ｎの負荷情報（実行能力）をＣＰＵ＃１に集約しないため、ＣＰＵ＃１への通信コンフリクトを回避することができる。

また、マルチコアシステム１００によれば、新たに起動されたアプリケーションＡＰの実行のためのアプリ情報１１０をＣＰＵ＃１がメモリ１０１から取得して、各ＣＰＵ＃２〜ＣＰＵ＃Ｎにブロードキャストすることができる。これにより、メモリ１０１上の同一データへのＣＰＵ＃２〜ＣＰＵ＃Ｎのアクセスコンテンションを回避することができる。すなわち、各ＣＰＵ＃２〜ＣＰＵ＃Ｎが、アプリケーションＡＰの実行可否を判定する際に、メモリ１０１からアプリ情報１１０をそれぞれ読み出す必要がないため、メモリ１０１上のアプリ情報１１０へのアクセスコンテンションを回避することができる。

また、マルチコアシステム１００によれば、ＣＰＵ＃２〜ＣＰＵ＃ＮのうちアプリケーションＡＰを実行可能なＣＰＵ（例えば、ＣＰＵ＃２）のみがＣＰＵ＃１への返答を行うため、スケジューリング時のＣＰＵ＃１への通信コンフリクトを回避することができる。

これらのことから、マルチコアシステム１００によれば、スケジューリング時の通信コストを削減して、効率的なスケジューリングを行うことができる。

（マルチコアシステム１００のシステム構成）
つぎに、実施の形態にかかるマルチコアシステム１００のシステム構成について説明する。

図２は、実施の形態にかかるマルチコアシステムのシステム構成例を示す説明図である。図２において、マルチコアシステム１００は、ＣＰＵ＃１〜ＣＰＵ＃Ｎと、メモリ１０１と、１次キャッシュ２０１−１〜２０１−Ｎと、スヌープ回路２０２と、２次キャッシュ２０３と、Ｉ／Ｆ（ＩｎｔｅｒＦａｃｅ）２０４と、メモリコントローラ２０５と、を有している。マルチコアシステム１００において、２次キャッシュ２０３と、Ｉ／Ｆ２０４と、メモリコントローラ２０５とは、バス２２０を介して接続されている。また、メモリ１０１は、メモリコントローラ２０５を介して各部と接続されている。

ＣＰＵ＃１は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）２１０−１を実行し、マルチコアシステム１００の全体の制御を司る。ＯＳ２１０−１は、マスタＯＳであり、アプリケーションをどのＣＰＵに割り当てるかを制御するスケジューラ２１０を備えている。また、ＣＰＵ＃１は、割り当てられたアプリケーションを実行する。ＣＰＵ＃２〜ＣＰＵ＃Ｎは、それぞれＯＳ＃２１０−２〜２１０−Ｎを実行し、各ＯＳに割り当てられたアプリケーションを実行する。ＯＳ＃２１０−２〜２１０−Ｎは、スレーブＯＳである。

ＣＰＵ＃１〜ＣＰＵ＃Ｎは、それぞれレジスタとコアとを有している。各レジスタには、プログラムカウンタやリセットレジスタがある。また、各ＣＰＵ＃１〜ＣＰＵ＃Ｎは、各々の１次キャッシュ２０１−１〜２０１−Ｎと、スヌープ回路２０２と、２次キャッシュ２０３とを介して各部に接続されている。

１次キャッシュ２０１−１〜２０１−Ｎは、それぞれキャッシュメモリとキャッシュコントローラとを有している。例えば、１次キャッシュ２０１−１は、ＯＳ２１０−１が実行するアプリケーションからメモリ１０１への書込処理を一時的に記憶する。１次キャッシュ２０１−１は、メモリ１０１から読み出されたデータを一時的に記憶する。

スヌープ回路２０２は、ＣＰＵ＃１〜ＣＰＵ＃Ｎがアクセスする１次キャッシュ２０１−１〜２０１−Ｎの整合性を取る。具体的には、例えば、スヌープ回路２０２は、１次キャッシュ２０１−１〜２０１−Ｎの間で共有するデータがいずれかの１次キャッシュで更新された場合、該更新を検出して、他の１次キャッシュを更新する。

２次キャッシュ２０３は、キャッシュメモリとキャッシュコントローラとを有している。２次キャッシュ２０３では、各１次キャッシュ２０１−１〜２０１−Ｎから追い出されたデータを記憶する。具体的には、例えば、２次キャッシュ２０３は、ＯＳ２１０−１〜２１０−Ｎで共有するデータを記憶する。

Ｉ／Ｆ２０４は、通信回線を通じてＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワークに接続され、ネットワークを介して他の装置に接続される。そして、Ｉ／Ｆ２０４は、ネットワークと内部のインターフェースを司り、外部の装置からのデータの入出力を制御する。

メモリコントローラ２０５は、メモリ１０１に対するデータのリード／ライトを制御する。メモリ１０１は、ＣＰＵ＃１〜ＣＰＵ＃Ｎに共有されるメモリである。メモリ１０１は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有している。

より具体的には、例えば、フラッシュＲＯＭが各ＯＳのプログラムを記憶し、ＲＯＭがアプリケーションプログラムを記憶し、ＲＡＭがＣＰＵ＃１〜ＣＰＵ＃Ｎのワークエリアとして使用される。メモリ１０１に記憶されているプログラムは、各ＣＰＵにロードされることで、コーディングされている処理を該各ＣＰＵに実行させることになる。

ファイルシステム２０７は、例えば、アプリケーションの命令コードや、画像および映像などのコンテンツデータを記憶している。ファイルシステム２０７は、例えば、ハードディスクや光ディスクなどの補助記憶装置により実現される。なお、図示は省略するが、マルチコアシステム１００は、各部に電源電圧を供給するＰＭＵ（Ｐｏｗｅｒ Ｍａｎａｇｅｍｅｎｔ Ｕｎｉｔ）のほか、ディスプレイやキーボードなどを有することにしてもよい。

（アプリケーションテーブル３００の記憶内容）
つぎに、マスタＣＰＵ（ＣＰＵ＃１）がアクセスするアプリケーションテーブル３００の記憶内容について説明する。アプリケーションテーブル３００は、例えば、図２に示したメモリ１０１に記憶されている。

図３は、アプリケーションテーブルの記憶内容の一例を示す説明図である。図３において、アプリケーションテーブル３００は、アプリＩＤ、Ｌ_min、Ｌ_maxおよびｍのフィールドを有する。各フィールドに情報を設定することで、アプリケーションＡＰ１〜ＡＰＫごとのアプリ情報３００−１〜３００−Ｋがレコードとして記憶されている。

ここで、アプリＩＤは、各アプリケーションＡＰ１〜ＡＰＫの識別子である。Ｌ_minは、各アプリケーションＡＰ１〜ＡＰＫに含まれる１以上のスレッド群のうち最小負荷のスレッドの負荷である。スレッドの負荷とは、該スレッドの実行にかかるＣＰＵの負荷である。Ｌ_maxは、各アプリケーションＡＰ１〜ＡＰＫに含まれる１以上のスレッド群のうち最大負荷のスレッドの負荷である。ｍは、各アプリケーションＡＰ１〜ＡＰＫに含まれるスレッド数である。

なお、本明細書において、ＣＰＵの最大計算能力、余剰計算能力、負荷、スレッドの負荷は、統一的な価値基準に従って、設定または算出される値によって表現される。ここでは、マスタＣＰＵであるＣＰＵ＃１の最大計算能力を「１．０」とする。また、スレーブＣＰＵである各ＣＰＵ＃２〜ＣＰＵ＃Ｎの最大計算能力は、ＣＰＵ＃１の動作周波数を基準として設定される。

例えば、ＣＰＵ＃２の動作周波数がＣＰＵ＃１の動作周波数と同じであれば、ＣＰＵ＃２の最大計算能力は「１．０」となる。例えば、ＣＰＵ＃２の動作周波数がＣＰＵ＃１の動作周波数の２倍であれば、ＣＰＵ＃２の最大計算能力は「２．０」となる。例えば、ＣＰＵ＃２の動作周波数がＣＰＵ＃１の動作周波数の半分であれば、ＣＰＵ＃２の最大計算能力は「０．５」となる。

また、ＣＰＵの負荷は、一定期間の間に該ＣＰＵの処理時間が占める割合によって表す。例えば、一定期間の間、常にＣＰＵ＃１が処理を行っている場合、ＣＰＵ＃１の負荷は「１．０」となる。また、一定期間のうちの半分の時間、ＣＰＵ＃１がアイドル状態となっている場合、ＣＰＵ＃１の負荷は「０．５」となる。

また、ＣＰＵの余剰計算能力は、ＣＰＵの最大計算能力からＣＰＵの負荷を減算した値によって表す。すなわち、ＣＰＵの余剰計算能力は、該ＣＰＵが有する残余の計算能力を表している。例えば、ＣＰＵ＃１の負荷が「０．５」の場合、ＣＰＵ＃１の余剰計算能力は「０．５」となる。

ここで、アプリ情報３００−１を例に挙げると、アプリケーションＡＰ１に含まれるスレッドの最小負荷Ｌ_minは「０．１」、最大負荷Ｌ_maxは「０．７」、スレッド数ｍは「２」である。すなわち、最大計算能力がＣＰＵ＃１と同一のＣＰＵが、最小負荷Ｌ_min「０．１」のスレッドを実行するためには、該ＣＰＵの余剰計算能力が「０．１以上」である必要がある。同様に、最大負荷Ｌ_max「０．７」のスレッドを実行するためには、該ＣＰＵの余剰計算能力が「０．７以上」である必要がある。

なお、以下の説明では、アプリケーションＡＰ１〜ＡＰＫのうち任意のアプリケーションを「アプリケーションＡＰｋ」と表記する（ｋ＝１，２，…，Ｋ）。また、アプリケーションＡＰｋに含まれるスレッドの最小負荷を「最小負荷Ｌｋ_min」、最大負荷を「最大負荷Ｌｋ_max」、スレッド数を「スレッド数ｍｋ」と表記する。

（マスタＣＰＵの機能的構成例）
つぎに、マスタＣＰＵ（ＣＰＵ＃１）の機能的構成例について説明する。図４は、実施の形態にかかるマスタＣＰＵの機能的構成を示すブロック図である。図４において、マスタＣＰＵは、受付部４０１と、読出部４０２と、通知部４０３と、判定部４０４と、割当部４０５と、を含む構成である。この制御部となる機能（受付部４０１〜割当部４０５）は、具体的には、例えば、メモリ１０１に記憶されたスケジューラ２１０をＣＰＵ＃１に実行させることにより、その機能を実現する。なお、各機能部の処理結果は、例えば、ＣＰＵ＃１のレジスタ、１次キャッシュ２０１−１、２次キャッシュ２０３およびメモリ１０１などの記憶装置に記憶される。

受付部４０１は、新たなアプリケーションＡＰｋの起動要求を受け付ける。アプリケーションＡＰｋの起動要求には、例えば、アプリケーションＡＰｋのアプリＩＤが含まれている。具体的には、例えば、受付部４０１が、アプリケーションＡＰｋの起動要求をＯＳ２１０−１から受け付ける。

読出部４０２は、アプリケーションＡＰｋの起動要求が受け付けられた場合、アプリケーションＡＰｋの実行のためのＣＰＵの計算能力に関する閾値をメモリ１０１から読み出す。ここで、ＣＰＵの計算能力に関する閾値とは、例えば、アプリケーションＡＰｋに含まれるスレッドの実行にかかるＣＰＵの負荷である。より具体的には、例えば、ＣＰＵの計算能力に関する閾値は、アプリケーションＡＰｋに含まれるスレッドの最小負荷Ｌｋ_minや最大負荷Ｌｋ_maxである。

具体的には、例えば、読出部４０２が、メモリ１０１にアクセスして、アプリケーションテーブル３００の中から、起動要求に含まれるアプリケーションＡＰｋのアプリＩＤに対応するアプリ情報３００−ｋを読み出す。アプリ情報３００−ｋには、アプリケーションＡＰｋのスレッドの最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxが含まれている。

通知部４０３は、アプリケーションＡＰｋの実行のためのＣＰＵの計算能力に関する閾値をＣＰＵ＃２〜ＣＰＵ＃Ｎに通知する。具体的には、例えば、通知部４０３が、アプリ情報３００−ｋから特定されるスレッドの最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxを、ＣＰＵ＃２〜ＣＰＵ＃Ｎにブロードキャストする。

また、受付部４０１は、アプリケーションＡＰｋの実行のためのＣＰＵの計算能力に関する閾値がＣＰＵ＃２〜ＣＰＵ＃Ｎに通知された結果、アプリケーションＡＰｋを実行できる旨の応答をＣＰＵ＃ｊから受け付ける（ｊ＝２，３，…，Ｎ）。具体的には、例えば、受付部４０１が、第１の応答通知または第２の応答通知をＣＰＵ＃ｊから受け付ける。

ここで、第１の応答通知とは、アプリケーションＡＰｋに含まれる最大負荷Ｌｋ_maxのスレッドを実行できる旨の応答である。すなわち、第１の応答通知は、アプリケーションＡＰｋに含まれるどのスレッドでもＣＰＵ＃ｊが実行できることを示すものである。

第２の応答通知とは、アプリケーションＡＰｋに含まれる最小負荷Ｌｋ_minのスレッドを実行できる旨の応答である。すなわち、第２の応答通知は、アプリケーションＡＰｋに含まれるスレッド群のうち、少なくとも最小負荷Ｌｋ_minのスレッドをＣＰＵ＃ｊが実行できることを示すものである。また、第２の応答通知には、例えば、ＣＰＵ＃ｊの余剰計算能力を示す情報が含まれている。

受け付けられた第１の応答通知は、例えば、図５に示す第１の応答通知リスト５００に記憶される。また、受け付けられた第２の応答通知は、例えば、図６に示す第２の応答通知リスト６００に記憶される。第１および第２の応答通知リスト５００，６００は、例えば、ＣＰＵ＃１のレジスタ、１次キャッシュ２０１−１、２次キャッシュ２０３およびメモリ１０１などの記憶装置により実現される。ここで、第１の応答通知リスト５００の具体例について説明する。

図５は、第１の応答通知リストの具体例を示す説明図である。図５において、第１の応答通知リスト５００は、アプリケーションＡＰｋに含まれる最大負荷Ｌｋ_maxのスレッドを実行できる旨の第１の応答通知があったＣＰＵごとのＣＰＵ情報（例えば、ＣＰＵ情報５００−１〜５００−３）をリスト化して示す情報である。

ここで、最大負荷は、起動要求があったアプリケーションＡＰｋに含まれるスレッドの最大負荷Ｌｋ_maxである。図５の例では、アプリケーションＡＰ１に含まれるスレッドの最大負荷Ｌ１_max「０．７」が示されている。ＣＰＵ名は、第１の応答通知のあったＣＰＵの識別子である。

割当フラグは、第１の応答通知のあったＣＰＵの割当状態を示すフラグである。割当フラグは、ＣＰＵにアプリケーションＡＰｋのスレッドが割り当てられていない場合は「０」、ＣＰＵにアプリケーションＡＰｋのスレッドが割り当てられた場合は「１」となる。なお、割当フラグは初期状態では「０」である。

ＣＰＵ情報５００−１を例に挙げると、アプリケーションＡＰ１に含まれる最大負荷Ｌ１_max「０．７」のスレッドを実行できる旨の第１の応答通知があったＣＰＵのＣＰＵ名「ＣＰＵ＃２」および割当フラグ「０」が示されている。このＣＰＵ情報５００−１は、ＣＰＵ＃２から第１の応答通知があった際に作成されて、第１の応答通知リスト５００に登録される。

つぎに、第２の応答通知リスト６００の具体例について説明する。

図６は、第２の応答通知リストの具体例を示す説明図である。図６において、第２の応答通知リスト６００は、アプリケーションＡＰｋに含まれる最小負荷Ｌｋ_minのスレッドを実行できる旨の第２の応答通知があったＣＰＵごとのＣＰＵ情報（例えば、ＣＰＵ情報６００−１〜６００−３）をリスト化して示す情報である。

ここで、最小負荷は、起動要求があったアプリケーションＡＰｋに含まれるスレッドの最小負荷Ｌｋ_minである。図６の例では、アプリケーションＡＰ１に含まれるスレッドの最小負荷Ｌ１_min「０．１」が示されている。ＣＰＵ名は、第２の応答通知のあったＣＰＵの識別子である。余剰計算能力は、第２の応答通知のあったＣＰＵの余剰計算能力である。

ＣＰＵ情報６００−１を例に挙げると、アプリケーションＡＰ１に含まれる最小負荷Ｌ１_min「０．１」のスレッドを実行できる旨の第２の応答通知があったＣＰＵのＣＰＵ名「ＣＰＵ＃３」および余剰計算能力「０．３」が示されている。このＣＰＵ情報６００−１は、ＣＰＵ＃３から第２の応答通知があった際に作成されて、第２の応答通知リスト６００に登録される。

なお、第１の応答通知リスト５００および第２の応答通知リスト６００の記憶内容は、例えば、アプリケーションＡＰｋのスレッドの最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxがＣＰＵ＃２〜ＣＰＵ＃Ｎにブロードキャストされると、その都度初期化される。

図４の説明に戻り、判定部４０４は、アプリケーションＡＰｋを実行できる旨の応答が受け付けられたＣＰＵの数が、アプリケーションＡＰｋに含まれるスレッド数ｍｋ以上となったか否かを判定する。スレッド数ｍｋは、アプリケーションＡＰｋの起動要求から特定される。

具体的には、例えば、判定部４０４は、アプリケーションＡＰｋに含まれる最大負荷Ｌｋ_maxのスレッドを実行できる旨の第１の応答通知があったＣＰＵの数（以下、「ＣＰＵ数Ｘ」という）が、スレッド数ｍｋ以上となったか否かを判定する（以下、「第１の判定処理」という）。

より具体的には、例えば、判定部４０４が、図５に示した第１の応答通知リスト５００を参照して、割当フラグが「０」のＣＰＵ情報を計数することにより、第１の応答通知があったＣＰＵ数Ｘを算出する。そして、判定部４０４が、算出したＣＰＵ数Ｘが、アプリケーションＡＰｋに含まれるスレッド数ｍｋ以上となったか否かを判定する。

また、判定部４０４は、アプリケーションＡＰｋに含まれる最小負荷Ｌｋ_minのスレッドを実行できる旨の第２の応答通知があったＣＰＵの数（以下、「ＣＰＵ数Ｙ」という）が、スレッド数ｍｋ以上となったか否かを判定する（以下、「第２の判定処理」という）。

より具体的には、例えば、判定部４０４が、図６に示した第２の応答通知リスト６００を参照して、ＣＰＵ情報を計数することにより、第２の応答通知があったＣＰＵ数Ｙを算出する。そして、判定部４０４が、算出したＣＰＵ数Ｙが、アプリケーションＡＰｋに含まれるスレッド数ｍｋ以上となったか否かを判定する。

第２の判定処理は、例えば、スレッドの最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxが通知されてから一定時間Ｔが経過しても、第１の判定処理においてＣＰＵ数Ｘがスレッド数ｍｋ未満であると判定された場合に実行されることにしてもよい。一定時間Ｔは、例えば、予め設定されてＣＰＵ＃１のレジスタ、１次キャッシュ２０１−１、２次キャッシュ２０３およびメモリ１０１などの記憶装置に記憶されている。

割当部４０５は、判定された判定結果に基づいて、アプリケーションＡＰｋに含まれるスレッド群をＣＰＵ＃２〜ＣＰＵ＃Ｎに割り当てる。具体的には、例えば、割当部４０５が、アプリケーションＡＰｋを実行できる旨の応答があったＣＰＵ＃ｊに、アプリケーションＡＰｋに含まれるスレッドを割り当てる。

以下、マスタＣＰＵ（ＣＰＵ＃１）のスケジューリング方法の具体的な処理内容について説明する。

＜スケジューリング方法１＞
まず、マスタＣＰＵ（ＣＰＵ＃１）のスケジューリング方法１について説明する。スケジューリング方法１は、上述した第１の判定処理の判定結果に基づいて、アプリケーションＡＰｋに含まれるスレッド群の割り当てを行うものである。

割当部４０５は、ＣＰＵ数Ｘがスレッド数ｍｋ以上の場合（第１の判定処理）、第１の応答通知リスト５００を参照して、割当フラグが「０」のＣＰＵに、アプリケーションＡＰｋに含まれるスレッド群をランダムに割り当てる。なお、スレッドをランダムに割り当てるとは、任意の選択アルゴリズムに基づいて、母集団となるＣＰＵ群の中からいずれかのＣＰＵを選択してスレッドを割り当てることである。

これにより、アプリケーションＡＰｋに含まれるスレッド群を、余剰計算能力が最大負荷Ｌｋ_max以上のＣＰＵ＃ｊに割り当てることができる。なお、アプリケーションＡＰｋのスレッドがＣＰＵ＃ｊに割り当てられた場合、第１の応答通知リスト５００内のＣＰＵ＃ｊの割当フラグが「０」から「１」に変更される。

一方、割当部４０５は、ＣＰＵ数Ｘがスレッド数ｍｋ未満の場合（第１の判定処理）、アプリケーションＡＰｋに含まれるスレッド群を、ＣＰＵ＃２〜ＣＰＵ＃Ｎにランダムに割り当てる。この際、割当部４０５は、ＣＰＵ＃２〜ＣＰＵ＃Ｎのうち第１の応答通知リスト５００内の割当フラグが「０」のＣＰＵを優先的に選択して、アプリケーションＡＰｋのスレッドを割り当てることにしてもよい。

これにより、ＣＰＵ＃２〜ＣＰＵ＃Ｎの中から余剰計算能力が最大負荷Ｌｋ_max以上のＣＰＵ＃ｊを優先的に選択して、アプリケーションＡＰｋに含まれるスレッドを割り当てることができる。

さらに、割当部４０５は、優先的に選択した第１の応答通知リスト５００内の割当フラグが「０」のＣＰＵに、アプリケーションＡＰｋの高負荷のスレッドを割り当てることにしてもよい。ここで、アプリケーションＡＰｋの各スレッドの負荷は、例えば、アプリケーションＡＰｋのスレッド負荷情報から特定される。

アプリケーションＡＰｋのスレッド負荷情報は、例えば、図３に示したアプリケーションＡＰｋのアプリ情報３００−ｋと関連付けてメモリ１０１に記憶されている。ここで、スレッド負荷情報の具体例について説明する。

図７は、スレッド負荷情報の具体例を示す説明図である。図７において、スレッド負荷情報７００は、アプリケーションＡＰ２に含まれる各スレッドｔ１〜ｔ５の負荷を示す情報である。具体的には、スレッドｔ１の負荷は「０．３」、スレッドｔ２の負荷は「０．４５」、スレッドｔ３の負荷は「０．５」、スレッドｔ４の負荷は「０．３５」、スレッドｔ５の負荷は「０．４」である。

この場合、割当部４０５は、優先的に選択した第１の応答通知リスト５００内の割当フラグが「０」のＣＰＵに、高負荷のスレッド（例えば、スレッドｔ３）を割り当てる。これにより、余剰計算能力が最大負荷Ｌｋ_max以上のＣＰＵ＃ｊに高負荷のスレッドを割り当てることができる。

＜スケジューリング方法２＞
つぎに、マスタＣＰＵ（ＣＰＵ＃１）のスケジューリング方法２について説明する。スケジューリング方法２は、上述した第２の判定処理の判定結果に基づいて、アプリケーションＡＰｋに含まれるスレッド群の割り当てを行うものである。

割当部４０５は、ＣＰＵ数Ｙがスレッド数ｍｋ以上の場合（第２の判定処理）、第２の応答通知リスト６００を参照して、第２の応答通知があったＣＰＵに、アプリケーションＡＰｋに含まれるスレッド群をランダムに割り当てる。これにより、アプリケーションＡＰｋに含まれるスレッド群を、余剰計算能力が最小負荷Ｌｋ_min以上のＣＰＵ＃ｊに割り当てることができる。

また、割当部４０５は、ＣＰＵ数Ｙがスレッド数ｍｋ以上の場合（第２の判定処理）、第２の応答通知リスト６００を参照して、余剰計算能力が大きいＣＰＵから順に、アプリケーションＡＰｋの高負荷のスレッドを割り当てることにしてもよい。

具体的には、例えば、割当部４０５が、スレッド負荷情報７００を参照して、余剰計算能力が大きいＣＰＵから順に、高負荷のスレッド（高：ｔ３→ｔ２→ｔ５→ｔ４→ｔ１：低）をそれぞれ割り当てる。これにより、余剰計算能力が最小負荷Ｌｋ_min以上のＣＰＵの中から余剰計算能力が高いＣＰＵ＃ｊを優先的に選択して高負荷のスレッドを割り当てることができる。

一方、割当部４０５は、ＣＰＵ数Ｙがスレッド数ｍｋ未満の場合（第２の判定処理）、アプリケーションＡＰｋに含まれるスレッド群を、ＣＰＵ＃２〜ＣＰＵ＃Ｎにランダムに割り当てる。この際、割当部４０５は、第２の応答通知リスト６００を参照して、第２の応答通知があったＣＰＵを優先的に選択して、アプリケーションＡＰｋのスレッドを割り当てることにしてもよい。

これにより、ＣＰＵ＃２〜ＣＰＵ＃Ｎの中から余剰計算能力が最小負荷Ｌｋ_min以上のＣＰＵ＃ｊを優先的に選択して、アプリケーションＡＰｋに含まれるスレッドを割り当てることができる。

さらに、割当部４０５は、優先的に選択した第２の応答通知があったＣＰＵに、アプリケーションＡＰｋの高負荷のスレッドを割り当てることにしてもよい。これにより、余剰計算能力が最小負荷Ｌｋ_min以上のＣＰＵ＃ｊに高負荷のスレッドを割り当てることができる。

＜スケジューリング方法３＞
つぎに、マスタＣＰＵ（ＣＰＵ＃１）のスケジューリング方法３について説明する。スケジューリング方法３は、後述する第３の判定処理の判定結果に基づいて、アプリケーションＡＰｋに含まれるスレッド群の割り当てを行うものである。

判定部４０４は、上述した一定時間Ｔ経過後において、ＣＰＵ数Ｘがスレッド数ｍｋ未満の場合（第１の判定処理）、ＣＰＵ数Ｙが、スレッド数ｍｋからＣＰＵ数Ｘを減算した値以上となったか否かを判定する（以下、「第３の判定処理」という）。なお、以下の説明では、スレッド数ｍｋからＣＰＵ数Ｘを減算した値を「残余のスレッド数（ｍｋ−Ｘ）」という。

割当部４０５は、ＣＰＵ数Ｙが残余のスレッド数（ｍｋ−Ｘ）以上の場合（第３の判定処理）、ＣＰＵ＃２〜ＣＰＵ＃Ｎのうち第１の応答通知リスト５００内の割当フラグが「０」のＣＰＵを優先的に選択して、アプリケーションＡＰｋのスレッドを割り当てる。この際、割当部４０５は、優先的に選択したＣＰＵにアプリケーションＡＰｋの高負荷のスレッドを割り当てることにしてもよい。

つぎに、割当部４０５は、第２の応答通知リスト６００を参照して、第２の応答通知があったＣＰＵに、アプリケーションＡＰｋのスレッド群のうち割り当てられていない残余のスレッドを割り当てる。この際、割当部４０５は、余剰計算能力が大きいＣＰＵから順に、高負荷のスレッドを割り当てることにしてもよい。

これにより、ＣＰＵ＃２〜ＣＰＵ＃Ｎの中から余剰計算能力が最大負荷Ｌｋ_max以上のＣＰＵ＃ｊを優先的に選択して、アプリケーションＡＰｋのスレッドを割り当てることができる。さらに、残余のスレッドを、余剰計算能力が最小負荷Ｌｋ_min以上のＣＰＵ＃ｊに割り当てることができる。

一方、割当部４０５は、ＣＰＵ数Ｙが残余のスレッド数（ｍｋ−Ｘ）未満の場合（第３の判定処理）、ＣＰＵ＃２〜ＣＰＵ＃Ｎのうち第１の応答通知リスト５００内の割当フラグが「０」のＣＰＵを優先的に選択して、アプリケーションＡＰｋのスレッドを割り当てる。

つぎに、割当部４０５は、第２の応答通知リスト６００を参照して、第２の応答通知があったＣＰＵを優先的に選択して、割り当てられていない残余のスレッドを割り当てる。そして、割当部４０５は、割り当てられていない残余のスレッドを、ＣＰＵ＃２〜ＣＰＵ＃Ｎにランダムに割り当てる。

これにより、ＣＰＵ＃２〜ＣＰＵ＃Ｎの中から余剰計算能力が最大負荷Ｌｋ_max以上のＣＰＵ＃ｊを優先的に選択して、アプリケーションＡＰｋのスレッドを割り当てることができる。さらに、余剰計算能力が最小負荷Ｌｋ_min以上のＣＰＵ＃ｊを優先的に選択して残余のスレッドを割り当てることができる。すなわち、アプリケーションＡＰｋのスレッド群を、ＣＰＵ＃２〜ＣＰＵ＃Ｎのうちできるだけ余剰計算能力が高いＣＰＵ＃ｊに割り当てることができる。

なお、上記判定部４０４は、通知部４０３によるアプリケーションＡＰｋのスレッドの最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxのブロードキャストに先立って、第１の応答通知リスト５００を参照して、第１の判定処理を実行することにしてもよい。すなわち、判定部４０４は、アプリケーションＡＰｋよりも前に割り当てられたアプリケーションＡＰｒ（ｒ≠ｋ）に関する第１の応答通知を利用して、アプリケーションＡＰｋの第１の判定処理を実行する。

具体的には、例えば、まず、判定部４０４は、前回割り当てられたアプリケーションＡＰｒのスレッドの最大負荷Ｌｒ_maxが、新たなアプリケーションＡＰｋのスレッドの最大負荷Ｌｋ_max以上か否かを判定する。なお、前回割り当てられたアプリケーションＡＰｒのスレッドの最大負荷Ｌｒ_maxは、例えば、第１の応答通知リスト５００から特定される。

ここで、最大負荷Ｌｒ_maxが最大負荷Ｌｋ_max以上の場合、判定部４０４は、第１の応答通知リスト５００を参照して、割当フラグが「０」のＣＰＵ情報を計数することによりＣＰＵ数Ｘを算出する。そして、判定部４０４は、算出したＣＰＵ数Ｘが、アプリケーションＡＰｋに含まれるスレッド数ｍｋ以上か否かを判定する。

これにより、アプリケーションＡＰｋのスレッドの最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxを、ＣＰＵ＃２〜ＣＰＵ＃Ｎにブロードキャストすることなく、第１の判定処理を行うことができる。

ただし、最大負荷Ｌｒ_maxが最大負荷Ｌｋ_max未満の場合は、通知部４０３により、アプリケーションＡＰｋのスレッドの最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxを、ＣＰＵ＃２〜ＣＰＵ＃Ｎにブロードキャストすることになる。同様に、ＣＰＵ数Ｘがスレッド数ｍｋ未満の場合は、通知部４０３により、アプリケーションＡＰｋのスレッドの最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxを、ＣＰＵ＃２〜ＣＰＵ＃Ｎにブロードキャストすることになる。

（スレーブＣＰＵの機能的構成例）
つぎに、スレーブＣＰＵ（ＣＰＵ＃２〜ＣＰＵ＃Ｎ）の機能的構成例について説明する。図８は、実施の形態にかかるスレーブＣＰＵの機能的構成を示すブロック図である。図８において、スレーブＣＰＵは、受付部８０１と、判定部８０２と、通知部８０３と、を含む構成である。この制御部となる機能（受付部８０１〜通知部８０３）は、具体的には、例えば、メモリ１０１に記憶されたプログラムを各ＣＰＵ＃２〜ＣＰＵ＃Ｎに実行させることにより、その機能を実現する。なお、各機能部の処理結果は、例えば、各ＣＰＵ＃２〜ＣＰＵ＃Ｎのレジスタ、１次キャッシュ２０１−２〜２０１−Ｎ、２次キャッシュ２０３およびメモリ１０１などの記憶装置に記憶される。

受付部８０１は、アプリケーションＡＰｋの実行のためのＣＰＵの計算能力に関する閾値をＣＰＵ＃１から受け付ける。具体的には、例えば、受付部８０１が、アプリケーションＡＰｋのスレッドの最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxをＣＰＵ＃１から受け付ける。

判定部８０２は、自ＣＰＵの計算能力が、受け付けられたアプリケーションＡＰｋの実行のためのＣＰＵの計算能力に関する閾値以上か否かを判定する。具体的には、例えば、判定部８０２が、自ＣＰＵの余剰計算能力が、アプリケーションＡＰｋのスレッドの最大負荷Ｌｋ_max以上か否かを判定する。また、判定部８０２が、自ＣＰＵの余剰計算能力が、アプリケーションＡＰｋのスレッドの最小負荷Ｌｋ_min以上か否かを判定する。

通知部８０３は、自ＣＰＵの計算能力がアプリケーションＡＰｋの実行のためのＣＰＵの計算能力に関する閾値以上の場合、アプリケーションＡＰｋを実行できる旨の応答をＣＰＵ＃１に通知する。具体的には、例えば、自ＣＰＵの余剰計算能力が最大負荷Ｌｋ_max以上の場合、通知部８０３が、第１の応答通知をＣＰＵ＃１に通知する。

また、自ＣＰＵの余剰計算能力が最小負荷Ｌｋ_min以上の場合、通知部８０３が、第２の応答通知をＣＰＵ＃１に通知する。この際、通知部８０３が、自ＣＰＵの余剰計算能力を含む第２の応答通知をＣＰＵ＃１に通知することにしてもよい。

（マスタＣＰＵの割当処理手順）
つぎに、マスタＣＰＵ（ＣＰＵ＃１）の割当処理手順について説明する。ここでは、上述したスケジューリング方法１とスケジューリング方法２とを組み合わせた場合のマスタＣＰＵ（ＣＰＵ＃１）の割当処理手順について説明する。

図９は、実施の形態にかかるマスタＣＰＵの割当処理手順の一例を示すフローチャートである。図９のフローチャートにおいて、まず、ＣＰＵ＃１により、新たなアプリケーションＡＰｋの起動要求を受け付けたか否かを判断する（ステップＳ９０１）。ここで、ＣＰＵ＃１により、起動要求を受け付けるのを待つ（ステップＳ９０１：Ｎｏ）。

そして、ＣＰＵ＃１により、起動要求を受け付けた場合（ステップＳ９０１：Ｙｅｓ）、アプリケーションテーブル３００の中から、起動要求に含まれるアプリケーションＡＰｋのアプリＩＤに対応するアプリ情報３００−ｋを読み出す（ステップＳ９０２）。

つぎに、ＣＰＵ＃１により、第１の応答通知リスト５００を参照して、前回割り当てられたアプリケーションＡＰｒのスレッドの最大負荷Ｌｒ_maxが、新たなアプリケーションＡＰｋのスレッドの最大負荷Ｌｋ_max以上か否かを判定する（ステップＳ９０３）。

ここで、最大負荷Ｌｒ_maxが最大負荷Ｌｋ_max未満の場合（ステップＳ９０３：Ｎｏ）、ＣＰＵ＃１により、アプリケーションＡＰｋのスレッドの最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxを、ＣＰＵ＃２〜ＣＰＵ＃Ｎにブロードキャストする（ステップＳ９０４）。なお、スレッドの最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxは、ステップＳ９０２において読み出したアプリ情報３００−ｋから特定される。

このあと、ＣＰＵ＃１により、ＣＰＵ＃ｊから第１の応答通知または第２の応答通知を受け付けたか否かを判断する（ステップＳ９０５）。ここで、ＣＰＵ＃１により、第１の応答通知または第２の応答通知を受け付けていない場合（ステップＳ９０５：Ｎｏ）、ステップＳ９０９に移行する。

一方、ＣＰＵ＃１により、第１の応答通知または第２の応答通知を受け付けた場合（ステップＳ９０５：Ｙｅｓ）、第１の応答通知リスト５００内の割当フラグが「０」のＣＰＵ情報を計数することで第１の応答通知があったＣＰＵ数Ｘを算出する（ステップＳ９０６）。そして、ＣＰＵ＃１により、算出したＣＰＵ数Ｘが、アプリケーションＡＰｋに含まれるスレッド数ｍｋ以上か否かを判定する（ステップＳ９０７）。

ここで、ＣＰＵ数Ｘがスレッド数ｍｋ以上の場合（ステップＳ９０７：Ｙｅｓ）、ＣＰＵ＃１により、第１の応答通知リスト５００内の割当フラグが「０」のＣＰＵに、アプリケーションＡＰｋのスレッド群をランダムに割り当てて（ステップＳ９０８）、本フローチャートによる一連の処理を終了する。

また、ステップＳ９０７において、ＣＰＵ数Ｘがスレッド数ｍｋ未満の場合（ステップＳ９０７：Ｎｏ）、ＣＰＵ＃１により、最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxをブロードキャストしてから一定時間Ｔ経過したか否かを判断する（ステップＳ９０９）。ここで、一定時間Ｔ経過していない場合（ステップＳ９０９：Ｎｏ）、ステップＳ９０５に戻る。

一方、一定時間Ｔ経過した場合（ステップＳ９０９：Ｙｅｓ）、ＣＰＵ＃１により、第２の応答通知リスト６００内のＣＰＵ情報を計数することで第２の応答通知があったＣＰＵ数Ｙを算出する（ステップＳ９１０）。そして、ＣＰＵ＃１により、算出したＣＰＵ数Ｙが、アプリケーションＡＰｋに含まれるスレッド数ｍｋ以上となったか否かを判定する（ステップＳ９１１）。

ここで、ＣＰＵ数Ｙがスレッド数ｍｋ以上の場合（ステップＳ９１１：Ｙｅｓ）、ＣＰＵ＃１により、第２の応答通知リスト６００内の余剰計算能力が大きいＣＰＵから順に高負荷のスレッドを割り当てて（ステップＳ９１２）、本フローチャートによる一連の処理を終了する。

一方、ＣＰＵ数Ｙがスレッド数ｍｋ未満の場合（ステップＳ９１１：Ｎｏ）、ＣＰＵ＃１により、アプリケーションＡＰｋのスレッド群をＣＰＵ＃２〜ＣＰＵ＃Ｎにランダムに割り当てて（ステップＳ９１３）、本フローチャートによる一連の処理を終了する。

また、ステップＳ９０３において、最大負荷Ｌｒ_maxが最大負荷Ｌｋ_max以上の場合（ステップＳ９０３：Ｙｅｓ）、ＣＰＵ＃１により、第１の応答通知リスト５００内の割当フラグが「０」のＣＰＵ情報を計数してＣＰＵ数Ｘを算出する（ステップＳ９１４）。

そして、ＣＰＵ＃１により、算出したＣＰＵ数Ｘが、アプリケーションＡＰｋに含まれるスレッド数ｍｋ以上か否かを判定する（ステップＳ９１５）。ここで、ＣＰＵ数Ｘがスレッド数ｍｋ以上の場合（ステップＳ９１５：Ｙｅｓ）、ステップＳ９０８に移行する。一方、ＣＰＵ数Ｘがスレッド数ｍｋ未満の場合（ステップＳ９１５：Ｎｏ）、ステップＳ９０４に移行する。

これにより、ＣＰＵ＃２〜ＣＰＵ＃Ｎの中から第１の応答通知があったＣＰＵ＃ｊを優先的に選択して、アプリケーションＡＰｋのスレッドを割り当てることができる。また、ＣＰＵ＃２〜ＣＰＵ＃Ｎの中から第２の応答通知があったＣＰＵ＃ｊを優先的に選択して、アプリケーションＡＰｋのスレッドを割り当てることができる。

なお、ステップＳ９０３において、前回割り当てられたアプリケーションＡＰｒが存在しない場合は、ステップＳ９０４に移行する。

（スレーブＣＰＵの判定処理手順）
つぎに、スレーブＣＰＵ（ＣＰＵ＃２〜ＣＰＵ＃Ｎ）の判定処理手順について説明する。ここでは、ＣＰＵ＃２〜ＣＰＵ＃ＮのうちのＣＰＵ＃ｊを例に挙げて、スレーブＣＰＵの判定処理手順について説明する。

図１０は、実施の形態にかかるスレーブＣＰＵの判定処理手順の一例を示すフローチャートである。図１０のフローチャートにおいて、まず、ＣＰＵ＃ｊにより、アプリケーションＡＰｋのスレッドの最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxをＣＰＵ＃１から受け付けたか否かを判断する（ステップＳ１００１）。

ここで、ＣＰＵ＃ｊにより、最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxを受け付けるのを待つ（ステップＳ１００１：Ｎｏ）。そして、ＣＰＵ＃ｊにより、最小負荷Ｌｋ_minおよび最大負荷Ｌｋ_maxを受け付けた場合（ステップＳ１００１：Ｙｅｓ）、自ＣＰＵの余剰計算能力が、アプリケーションＡＰｋのスレッドの最大負荷Ｌｋ_max以上か否かを判定する（ステップＳ１００２）。

ここで、自ＣＰＵの余剰計算能力が最大負荷Ｌｋ_max以上の場合（ステップＳ１００２：Ｙｅｓ）、ＣＰＵ＃ｊにより、第１の応答通知をＣＰＵ＃１に通知して（ステップＳ１００３）、本フローチャートによる一連の処理を終了する。

一方、自ＣＰＵの余剰計算能力が最大負荷Ｌｋ_max未満の場合（ステップＳ１００２：Ｎｏ）、ＣＰＵ＃ｊにより、自ＣＰＵの余剰計算能力が、アプリケーションＡＰｋのスレッドの最小負荷Ｌｋ_min以上か否かを判定する（ステップＳ１００４）。

ここで、自ＣＰＵの余剰計算能力が最小負荷Ｌｋ_min以上の場合（ステップＳ１００４：Ｙｅｓ）、ＣＰＵ＃ｊにより、第２の応答通知をＣＰＵ＃１に通知して（ステップＳ１００５）、本フローチャートによる一連の処理を終了する。一方、自ＣＰＵの余剰計算能力が最小負荷Ｌｋ_min未満の場合（ステップＳ１００４：Ｎｏ）、本フローチャートによる一連の処理を終了する。

これにより、自ＣＰＵの余剰計算能力が最大負荷Ｌｋ_max以上の場合に第１の応答通知をＣＰＵ＃１に通知することができる。また、自ＣＰＵの余剰計算能力が最小負荷Ｌｋ_min以上の場合に第２の応答通知をＣＰＵ＃１に通知することができる。

以上説明した実施の形態にかかるマルチコアシステム１００によれば、ＣＰＵ＃１からＣＰＵ＃ｊにアプリケーションＡＰｋのスレッドの最大負荷Ｌｋ_maxを通知して、最大負荷Ｌｋ_maxのスレッドの実行可否をＣＰＵ＃ｊに判定させることができる。また、マルチコアシステム１００によれば、ＣＰＵ＃２〜ＣＰＵ＃Ｎの中から第１の応答通知があったＣＰＵ＃ｊを優先的に選択して、アプリケーションＡＰｋのスレッドを割り当てることができる。これにより、アプリケーションＡＰｋのスレッドを、余剰計算能力が最大負荷Ｌｋ_max以上のＣＰＵ＃ｊに割り当てることができる。

また、マルチコアシステム１００によれば、ＣＰＵ＃１からＣＰＵ＃ｊにアプリケーションＡＰｋのスレッドの最小負荷Ｌｋ_minを通知して、最小負荷Ｌｋ_minのスレッドの実行可否をＣＰＵ＃ｊに判定させることができる。また、マルチコアシステム１００によれば、ＣＰＵ＃２〜ＣＰＵ＃Ｎの中から第２の応答通知があったＣＰＵ＃ｊを優先的に選択して、アプリケーションＡＰｋのスレッドを割り当てることができる。これにより、アプリケーションＡＰｋのスレッドを、余剰計算能力が最小負荷Ｌｋ_min以上のＣＰＵ＃ｊに割り当てることができる。

また、マルチコアシステム１００によれば、まず、第１の応答通知があったＣＰＵを選択してアプリケーションＡＰｋのスレッドを割り当て、つぎに、第２の応答通知があったＣＰＵを選択して残余のスレッドを割り当てることができる。これにより、アプリケーションＡＰｋのスレッドをできるだけ余剰計算能力が高いＣＰＵ＃ｊに割り当てることができ、負荷分散の適正化を図ることができる。

また、マルチコアシステム１００によれば、できるだけ余剰計算能力が高いＣＰＵ＃ｊに高負荷のスレッドを割り当てることにより、負荷分散の適正化を図ることができる。

また、マルチコアシステム１００によれば、前回割り当てたアプリケーションＡＰｒの最大負荷Ｌｒ_maxのスレッドを実行できる旨の第１の応答通知があったＣＰＵ＃ｊを優先的に選択して、アプリケーションＡＰｋのスレッドを割り当てることができる。この際、アプリケーションＡＰｒの最大負荷Ｌｒ_maxがアプリケーションＡＰｋの最大負荷Ｌｋ_max以上の場合に、ＣＰＵ＃１が前回第１の応答通知があったＣＰＵ＃ｊを優先的に選択する。これにより、アプリケーションＡＰｋのスレッドの最大負荷Ｌｋ_maxをブロードキャストすることなく、余剰計算能力が最大負荷Ｌｋ_max以上のＣＰＵ＃ｊを選択でき、通信コスト（通信量、通信処理）を削減することができる。

これらのことから、スケジューリング方法およびスケジューリングシステムによれば、新たに起動されたアプリケーションのスケジューリングを効率的に行うことができる。この結果、スケジューリングにかかる処理時間や通信時間が性能ボトルネックとなることを防いで、スケジューリングシステムの高性能化を図ることができる。

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

１００ マルチコアシステム
１０１ メモリ
３００ アプリケーションテーブル
４０１，８０１ 受付部
４０２ 読出部
４０３，８０３ 通知部
４０４，８０２ 判定部
４０５ 割当部
５００ 第１の応答通知リスト
６００ 第２の応答通知リスト
７００ スレッド負荷情報
＃１〜＃Ｎ ＣＰＵ

Claims (12)

1. 第１アプリケーションの起動時に第１ＣＰＵが前記第１アプリケーションの実行のための第１閾値を取得し、
   前記第１ＣＰＵが前記第１閾値を第２ＣＰＵに送信し、
   前記第２ＣＰＵの実行能力が前記第１閾値以上であるときは前記第２ＣＰＵは前記第１ＣＰＵに前記第１アプリケーションを実行できる旨を通知し、
   前記第２ＣＰＵの実行能力が前記第１閾値よりも小さいときは前記第２ＣＰＵは前記第１ＣＰＵへの通知を行わないこと
   を特徴とするスケジューリング方法。
2. 前記第１ＣＰＵは、前記第１閾値以上の実行能力を有するＣＰＵの数が前記第１アプリケーションで生成されるスレッドの数未満であるとき、前記第１閾値を前記第２ＣＰＵに送信すること
   を特徴とする請求項１に記載のスケジューリング方法。
3. 前記第１ＣＰＵは、前記第１閾値が第２アプリケーションの起動時に取得した第２閾値以上であるときは、前記第１閾値を前記第２ＣＰＵに送信すること
   を特徴とする請求項１または請求項２に記載のスケジューリング方法。
4. 前記第１閾値が前記第２ＣＰＵに送信されないとき、前記第１ＣＰＵは前記第１アプリケーションをＣＰＵにランダムに割り当てること
   を特徴とする請求項１乃至請求項３の何れか一に記載のスケジューリング方法。
5. 前記第２ＣＰＵの実行能力が前記第１閾値より大きいとき前記第２ＣＰＵは前記第１ＣＰＵに前記第１アプリケーションを実行する旨を通知し、
   前記第２ＣＰＵの実行能力が前記第１閾値より小さいときに前記実行能力を第３閾値と比較すること
   を特徴とする請求項１乃至請求項４の何れか一に記載のスケジューリング方法。
6. 前記第１閾値は前記第１アプリケーションの実行のための最大能力に対応し、
   前記第３閾値は前記第１アプリケーションの実行のための最小能力に対応すること
   を特徴とする請求項５に記載のスケジューリング方法。
7. 前記第１閾値の通知から所定期間経過後に、前記第３閾値以上の実行能力を有する第３ＣＰＵの数が前記第１アプリケーションで生成されるスレッドの数以上であるとき、前記第３ＣＰＵの内の実行能力の大きいＣＰＵに前記第１アプリケーションを割り当てること
   を特徴とする請求項５または請求項６に記載のスケジューリング方法。
8. 前記第３閾値以上の実行能力を有する第３ＣＰＵの数が前記第１アプリケーションで生成されるスレッドの数より少ないとき、前記第１アプリケーションをＣＰＵにランダムに割り当てること
   を特徴とする請求項５または請求項６に記載のスケジューリング方法。
9. 第１アプリケーションの実行のための第１閾値を格納するメモリと、
   前記第１アプリケーションの起動時に前記第１閾値を取得する第１ＣＰＵと、
   実行能力が前記第１ＣＰＵから供給される前記第１閾値以上であるときは前記第１ＣＰＵに前記第１アプリケーションを実行できる旨を通知し、前記実行能力が前記第１閾値よりも小さいときは前記第１ＣＰＵに通知しない第２ＣＰＵと
   を含むことを特徴とするスケジューリングシステム。
10. 前記第１ＣＰＵは、前記第１閾値以上の実行能力を有するＣＰＵの数が前記第１アプリケーションで生成されるスレッドの数未満であるとき、前記第１閾値を前記第２ＣＰＵに送信すること
    を特徴とする請求項９に記載のスケジューリングシステム。
11. 前記第１ＣＰＵは、前記第１閾値が第２アプリケーションの起動時に取得した第２閾値以上であるときは、前記第１閾値を前記第２ＣＰＵに送信すること
    を特徴とする請求項９または請求項１０に記載のスケジューリングシステム。
12. 前記第２ＣＰＵは、前記第２ＣＰＵの実行能力が前記第１閾値より大きいとき前記第１ＣＰＵに前記第１アプリケーションを実行する旨を通知し、前記第２ＣＰＵの実行能力が前記第１閾値より小さいときに前記実行能力を第３閾値と比較すること
    を特徴とする請求項９乃至請求項１１の何れか一に記載のスケジューリングシステム。

Images