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

Abstract

スケジューラ（１０１）は、アプリ（＃５）の起動通知を受け付ける。スケジューラ（１０１）は、アプリケーション情報テーブル（１０２）を参照して、ＣＰＵ（＃０）およびＣＰＵ（＃１）に割り当てられているアプリ（＃０）〜アプリ（＃４）のうち、新たに起動されたアプリ（＃５）と同時に実行され得るアプリを特定する。スケジューラ（１０１）は、マルチコアプロセッサシステム（１００）内のＣＰＵ（＃０）およびＣＰＵ（＃１）のうち、アプリ（＃５）と同時に実行され得るアプリ（＃０）およびアプリ（＃１）が割り当てられていないＣＰＵ（＃１）を検出する。スケジューラ（１０１）は、アプリ（＃５）をＣＰＵ（＃１）に割り当てる。これにより、新たに起動されたアプリ（＃５）を、アプリ（＃５）と同時に実行される可能性が高いアプリ（＃０）およびアプリ（＃１）が割り当てられていないＣＰＵ（＃１）に割り当てることができる。

Description

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

近年、多くの情報機器において、高性能および低消費電力に対する要求は大きく、高性能および低消費電力化を実現するための手段として、マルチコアプロセッサを用いたシステム開発が行われるようになってきた。

関連する先行技術としては、例えば、マイクロコンピュータにおけるタスクの切り替えに関するものがある（例えば、下記特許文献１，２参照。）。また、複数のプロセッサコアの電力制御に関する技術がある（例えば、下記特許文献３参照。）。

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

しかしながら、従来のマルチコアプロセッサシステムでは、マルチタスク動作時に、同一ＣＰＵに頻繁に切り替えられるアプリケーションが割り当てられる場合があり、アプリケーションの切り替えにかかる時間の増大化を招くという問題があった。

本発明は、上述した従来技術による問題点を解消するため、アプリケーションの切り替えの高速化を図ることができるスケジューリング方法およびスケジューリングシステムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明の一側面によれば、複数のプロセッサを管理するスケジューラが、第１アプリケーションが起動されたときに、アプリケーション情報テーブルに基づいて、前記第１アプリケーションと同時に実行されることのない第２アプリケーションを実行するプロセッサを検出し、前記プロセッサに前記第１アプリケーションを割り当てるスケジューリング方法が提案される。

また、上述した課題を解決し、目的を達成するため、本発明の一側面によれば、複数のプロセッサを管理するスケジューラが、第１アプリケーションが起動されたときに、アプリケーション情報テーブルに基づいて、前記複数のプロセッサの少なくとも一のプロセッサで実行される第２アプリケーションを前記第１アプリケーションに切り替えるときの負荷を計算し、前記負荷に基づいて前記第１アプリケーションを実行する第１プロセッサを選択するスケジューリング方法が提案される。

また、上述した課題を解決し、目的を達成するため、本発明の一側面によれば、複数のプロセッサと、前記複数のプロセッサを管理するスケジューラと、を含み、前記スケジューラは、第１アプリケーションの起動タスクを受信したときに、アプリケーション情報テーブルに基づいて、前記複数のプロセッサの少なくとも一のプロセッサで実行される第２アプリケーションを前記第１アプリケーションに切り替えるときの負荷を計算し、前記負荷に基づいて前記第１アプリケーションを実行する第１プロセッサを選択するスケジューリングシステムが提案される。

本発明の一側面によれば、アプリケーションの切り替えの高速化を図ることができるという効果を奏する。

図１は、実施の形態にかかるスケジューリング処理の一実施例を示す説明図（その１）である。 図２は、実施の形態にかかるスケジューリング処理の一実施例を示す説明図（その２）である。 図３は、実施の形態にかかるマルチコアプロセッサシステムのシステム構成例を示す説明図である。 図４は、ユースケーステーブルの記憶内容の一例を示す説明図である。 図５は、実施の形態にかかるスケジューラの機能的構成を示すブロック図である。 図６は、割当テーブルの記憶内容の一例を示す説明図である。 図７は、アプリケーションの割当例を示す説明図である。 図８は、割当先候補コストテーブルの記憶内容の一例を示す説明図である。 図９は、マイグレーション先候補コストテーブルの記憶内容の一例を示す説明図である。 図１０は、実施の形態にかかるスケジューラによるスケジューリング処理手順の一例を示すフローチャート（その１）である。 図１１は、実施の形態にかかるスケジューラによるスケジューリング処理手順の一例を示すフローチャート（その２）である。 図１２は、マイグレーション処理の具体的処理手順の一例を示すフローチャートである。

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

（スケジューリング処理の一実施例）
図１および図２は、実施の形態にかかるスケジューリング処理の一実施例を示す説明図である。図１および図２において、マルチコアプロセッサシステム１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）＃０と、ＣＰＵ＃１と、を含むスケジューリングシステムである。

ＣＰＵ＃０は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）＃０を実行し、マルチコアプロセッサシステム１００の全体の制御を司る。ＯＳ＃０は、マスタＯＳであり、アプリケーションをどのＣＰＵに割り当てるかを制御するスケジューラ１０１を備えている。また、ＣＰＵ＃０は、割り当てられたアプリケーションを実行する。ＣＰＵ＃１は、ＯＳ＃１を実行し、ＯＳ＃１に割り当てられたアプリケーションを実行する。ＯＳ＃１は、スレーブＯＳである。なお、アプリ（アプリケーション）が割り当てられているＣＰＵとアプリが割り当てられているＯＳとは同一の意味である。

以下、図１を用いて、新たなアプリ＃５が起動された場合を例に挙げて、マルチコアプロセッサシステム１００のスケジューリング処理の第１の実施例について説明する。

（１−１）スケジューラ１０１は、アプリ＃５の起動通知を受け付ける。

（１−２）スケジューラ１０１は、アプリケーション情報テーブル１０２を参照して、ＣＰＵ＃０およびＣＰＵ＃１に割り当てられているアプリ＃０〜アプリ＃４のうち、新たに起動されたアプリ＃５と同時に実行され得るアプリを特定する。

ここで、アプリケーション情報テーブル１０２は、アプリケーションごとに、該アプリケーションと同時に実行され得る他のアプリケーション情報を含むものである。例えば、アプリ＃５をゲームアプリとすると、動画再生アプリや音楽再生アプリなどは、同時に実行される可能性が低いアプリである。一方、アプリ＃５を音楽再生アプリとすると、電子メールアプリやウェブブラウザなどは、上述したゲームアプリと動画再生アプリのような組合せに比べて、同時に実行される可能性が高いアプリである。

アプリケーション情報テーブル１０２は、音楽再生アプリと電子メールアプリのような、同時に実行される可能性が高いアプリの組合せを示す。図１の例では、アプリ＃５と同時に実行され得るアプリとして、アプリ＃０およびアプリ＃１が特定されている。なお、アプリケーション情報テーブル１０２の詳細な説明は、図４を用いて後述する。

（１−３）スケジューラ１０１は、マルチコアプロセッサシステム１００内のＣＰＵ＃０およびＣＰＵ＃１のうち、アプリ＃５と同時に実行されることのないアプリを実行するＣＰＵを検出する。具体的には、例えば、スケジューラ１０１が、ＣＰＵ＃０およびＣＰＵ＃１のうち、アプリ＃５と同時に実行され得るアプリ＃０およびアプリ＃１が割り当てられていないＣＰＵ＃１を検出する。

（１−４）スケジューラ１０１は、アプリ＃５をＣＰＵ＃１に割り当てる。これにより、新たに起動されたアプリ＃５を、アプリ＃５と同時に実行される可能性が高いアプリ＃０およびアプリ＃１が割り当てられているＣＰＵ＃０とは異なるＣＰＵ＃１に割り当てることができる。

このように、実施の形態にかかるスケジューラ１０１によれば、同時に実行される可能性が高いアプリを異なるＣＰＵにそれぞれ割り当てることができる。この結果、例えば、アプリ＃５とアプリ＃０（またはアプリ＃１）との切り替えが発生した際に、アプリ＃５，アプリ＃０のコンテキスト情報の退避やロードが不要となるため、アプリ＃５，アプリ＃０間の切り替えを高速に行うことができる。

つぎに、図２を用いて、アプリ＃５が起動された場合を例に挙げて、マルチコアプロセッサシステム１００のスケジューリング処理の第２の実施例について説明する。

（２−１）スケジューラ１０１は、アプリ＃５の起動通知を受け付ける。

（２−２）スケジューラ１０１は、アプリケーション情報テーブル１０２を参照して、ＣＰＵ＃０およびＣＰＵ＃１に割り当てられているアプリ＃０〜アプリ＃４のうち、新たに起動されたアプリ＃５と同時に実行され得るアプリを特定する。図２の例では、アプリ＃５と同時に実行され得るアプリとして、アプリ＃０、アプリ＃１、アプリ＃３およびアプリ＃４が特定されている。

（２−３）スケジューラ１０１は、アプリケーション情報テーブル１０２を参照して、ＣＰＵ＃０およびＣＰＵ＃１の少なくとも一のＣＰＵで実行されるアプリを、新たに起動されたアプリ＃５に切り替えるときの負荷を計算する。

ここで、アプリケーション情報テーブル１０２は、アプリケーションごとに、該アプリケーションのコンテキスト負荷情報を含むものである。コンテキスト負荷情報は、実行中の一のアプリケーションを他のアプリケーションに切り替えるときにかかる負荷に関する情報である。

具体的には、例えば、スケジューラ１０１が、新たに起動されたアプリ＃５のコンテキスト負荷情報に基づいて、ＣＰＵ＃０に割り当てられているアプリ＃０およびアプリ＃１を、アプリ＃５に切り替えるときの各々の負荷の合計を計算する。アプリ＃０およびアプリ＃１は、アプリ＃５と同時に実行され得るアプリである。

また、スケジューラ１０１が、新たに起動されたアプリ＃５のコンテキスト負荷情報に基づいて、ＣＰＵ＃１に割り当てられているアプリ＃３およびアプリ＃４を、アプリ＃５に切り替えるときの各々の負荷の合計を計算する。アプリ＃３およびアプリ＃４は、アプリ＃５と同時に実行され得るアプリである。

（２−４）スケジューラ１０１は、計算した負荷に基づいて、ＣＰＵ＃０およびＣＰＵ＃１の中からアプリ＃５を実行するＣＰＵを選択して、アプリ＃５を割り当てる。具体的には、例えば、スケジューラ１０１が、ＣＰＵ＃０およびＣＰＵ＃１のうち、計算した負荷の合計が最小となるＣＰＵを選択して、アプリ＃５を割り当てる。ここでは、ＣＰＵ＃０が選択されて、アプリ＃５が割り当てられている。

このように、実施の形態にかかるスケジューラ１０１によれば、アプリ間の切り替えにかかる負荷を考慮して、新たに起動されたアプリの割当先となるＣＰＵを選択することができる。この結果、例えば、アプリ＃５とアプリ＃０との切り替えが発生した際の負荷を抑えることができ、アプリ間の切り替えの高速化を図ることができる。

（マルチコアプロセッサシステム３００のシステム構成）
つぎに、実施の形態にかかるマルチコアプロセッサシステム３００のシステム構成について説明する。なお、図１および図２に示したマルチコアプロセッサシステム１００は、以下に説明するマルチコアプロセッサシステム３００の一例である。

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

ＣＰＵ＃０は、ＯＳ＃０を実行し、マルチコアプロセッサシステム３００の全体の制御を司る。ＯＳ＃０は、マスタＯＳであり、アプリケーションをどのＣＰＵに割り当てるかを制御するスケジューラ１０１を備えている。また、ＣＰＵ＃０は、割り当てられたアプリケーションを実行する。ＣＰＵ＃１〜ＣＰＵ＃ｎは、それぞれＯＳ＃１〜ＯＳ＃ｎを実行し、各ＯＳに割り当てられたアプリケーションを実行する。ＯＳ＃１〜ＯＳ＃ｎは、スレーブＯＳである。

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

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

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

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

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

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

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

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

（ユースケーステーブル４００の記憶内容）
つぎに、図３に示したスケジューラ１０１が用いるユースケーステーブル４００について説明する。ユースケーステーブル４００は、図１および図２に示したアプリケーション情報テーブル１０２に相当する。ユースケーステーブル４００は、例えば、１次キャッシュ３０１−１、２次キャッシュ３０３、メモリ３０６などに記憶されている。

図４は、ユースケーステーブルの記憶内容の一例を示す説明図である。図４において、ユースケーステーブル４００は、アプリ名、コンテキストコスト、同時実行アプリおよび期待値のフィールドを有する。各フィールドに情報を設定することで、アプリごとのアプリケーション情報（例えば、アプリケーション情報４００−１〜４００−６）がレコードとして記憶されている。

アプリ名は、アプリを識別する名称である。コンテキストコストは、アプリのコンテキストスイッチにかかる負荷を表す指標値であり、例えば、アプリの起動や停止にかかる時間によって表される。より具体的には、例えば、コンテキストコストは、アプリのコンテキスト情報のメモリ３０６への退避（または、メモリ３０６からのロード）にかかる時間によって表される。なお、コンテキスト情報とは、各ＣＰＵのプログラムカウンタの値や、関数内の変数の値を格納する汎用レジスタの値などの情報である。

同時実行アプリは、各アプリと同時に実行される可能性が高いアプリを識別する情報である。期待値は、各アプリが同時実行アプリに切り替わる割合を示すものであり、例えば、各アプリを１回実行している間に、該アプリが同時実行アプリに切り替わる割合によって表されている。

一例として、アプリケーション情報４００−１を例に挙げると、アプリ＃０のコンテキストコスト『１００［ｕｓ］』が示されている。すなわち、アプリ＃０のコンテキスト情報の退避（または、ロード）にかかる時間は１００［ｕｓ］である。また、アプリ＃０の同時実行アプリ『アプリ＃３、アプリ＃４、アプリ＃５』が示されている。すなわち、アプリ＃０と同時に実行される可能性が高いアプリは、アプリ＃３、アプリ＃４およびアプリ＃５である。また、同時実行アプリごとの期待値が示されている。具体的には、例えば、アプリ＃０を実行中に、アプリ＃０からアプリ＃３に切り替わる割合は『０．４』である。また、例えば、アプリ＃０を実行中に、アプリ＃０からアプリ＃４に切り替わる割合は『０．６』である。また、例えば、アプリ＃０を実行中に、アプリ＃０からアプリ＃５に切り替わる割合は『０．５』である。

なお、ユースケーステーブル４００内の各アプリのコンテキストコストは、例えば、マルチコアプロセッサシステム３００の設計時に、シミュレーションによって各アプリのコンテキスト情報の退避時間を測定することにより求めることにしてもよい。また、ユースケーステーブル４００内の各アプリの同時実行アプリおよび期待値は、例えば、ユーザがアプリを使用するたびに、ＯＳ＃０が、アプリの切り替え回数の期待値を計算して更新することにしてもよい。

なお、以下の説明において、特に指定する場合を除き、マルチコアプロセッサシステム３００内のＣＰＵ＃０〜ＣＰＵ＃ｎのうち任意のＣＰＵを「ＣＰＵ＃ｉ」と表記する（ｉ＝０，１，…，ｎ）。

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

受付部５０１は、新たなアプリ（以下、「アプリ＃ｊ」という）の起動通知を受け付ける。具体的には、例えば、受付部５０１が、アプリ＃ｊの起動通知をＯＳ＃０から受け付ける。

特定部５０２は、ユースケーステーブル４００（図４参照）を参照して、起動通知が受け付けられたアプリ＃ｊと同時に実行され得るアプリ（以下、「アプリ＃ｋ」という）を特定する。

一例として、アプリ＃５の起動通知を受け付けた場合を想定する（ｊ＝５）。この場合、特定部５０２が、ユースケーステーブル４００の中から、アプリ＃５に対応するアプリケーション情報４００−６を特定する。そして、特定部５０２が、アプリケーション情報４００−６を参照して、アプリ＃５と同時に実行され得るアプリ＃０，アプリ＃１，アプリ＃３，アプリ＃４を特定する。

検出部５０３は、マルチコアプロセッサシステム３００内のＣＰＵ＃０〜ＣＰＵ＃ｎの中から、新たなアプリ＃ｊと同時に実行され得るアプリ＃ｋが割り当てられていないＣＰＵを検出する。具体的には、例えば、検出部５０３が、図６に示す割当テーブル６００を参照して、アプリ＃ｋが割り当てられていないＣＰＵを検出する。

割当テーブル６００は、ＣＰＵ＃０〜ＣＰＵ＃ｎにそれぞれ割り当てられているアプリ、具体的には、各ＣＰＵ＃０〜ＣＰＵ＃ｎの待ち行列に登録されているアプリを示す情報である。割当テーブル６００は、例えば、１次キャッシュ３０１−１、２次キャッシュ３０３およびメモリ３０６などにより実現される。ここで、割当テーブル６００について説明する。

図６は、割当テーブルの記憶内容の一例を示す説明図である。図６において、割当テーブル６００には、各ＣＰＵ＃０〜ＣＰＵ＃ｎに割り当てられているアプリ名が示されている。ＣＰＵ＃０を例に挙げると、アプリ＃０，アプリ＃１およびアプリ＃２が割り当てられている。なお、割当テーブル６００の記憶内容は、各ＣＰＵ＃０〜ＣＰＵ＃ｎに割り当てられるアプリの変更に合わせて、その都度更新される。

図５の説明に戻り、割当部５０４は、検出された、新たなアプリ＃ｊと同時に実行され得るアプリ＃ｋが割り当てられていないＣＰＵ（以下、「ＣＰＵ＃Ａ」という）にアプリ＃ｊを割り当てる。具体的には、例えば、割当部５０４が、ＣＰＵ＃Ａの待ち行列にアプリ＃ｊを登録する。

これにより、新たなアプリ＃ｊを、同時に実行される可能性が高いアプリ＃ｋが割り当てられていないＣＰＵ＃Ａに割り当てることができる。この結果、アプリ＃ｊとアプリ＃ｋとの切り替えが発生した際に、アプリ＃ｊ，アプリ＃ｋのコンテキスト情報の退避やロードが不要となるため、アプリ間の切り替えを高速に行うことができる。

第１の算出部５０５は、新たなアプリ＃ｊと同時に実行され得るアプリ＃ｋが割り当てられていないＣＰＵが複数検出された場合、検出された各ＣＰＵの負荷を算出する。具体的には、例えば、第１の算出部５０５が、検出された各ＣＰＵに割り当てられているアプリの数や各アプリの実行時間に基づいて、該各ＣＰＵの負荷を算出する。より具体的には、例えば、第１の算出部５０５が、検出された各ＣＰＵに割り当てられているアプリの数を、該各ＣＰＵの負荷として算出することにしてもよい。

また、割当部５０４は、算出された各ＣＰＵの負荷に基づいて、検出された複数のＣＰＵの中から、新たなアプリ＃ｊの割当先となるＣＰＵ＃Ａを選択する。具体的には、例えば、割当部５０４が、検出された複数のＣＰＵの中から、算出された負荷が最小となるＣＰＵ＃Ａを選択する。そして、割当部５０４は、選択したＣＰＵ＃Ａにアプリ＃ｊを割り当てる。

これにより、新たなアプリ＃ｊを、同時に実行される可能性が高いアプリ＃ｋが割り当てられていないＣＰＵのうち、負荷が最小のＣＰＵ＃Ａに割り当てることができる。この結果、アプリ間の切り替えを高速に行うとともに、ＣＰＵ＃０〜ＣＰＵ＃ｎに負荷を分散してシステム全体の性能を向上させることができる。

第２の算出部５０６は、新たなアプリ＃ｊと同時に実行され得るアプリ＃ｋが割り当てられていないＣＰＵが検出されなかった場合、新たなアプリ＃ｊと、ＣＰＵ＃ｉに割り当てられているアプリ＃ｋとを切り替えるときの負荷（以下、「切替コスト」という）を算出する。

具体的には、例えば、第２の算出部５０６が、ＣＰＵ＃ｉに割り当てられているアプリ＃ｋのコンテキストの切替時間と、該アプリ＃ｋと新たなアプリ＃ｊとの切替回数の期待値とに基づいて、切替コストを算出する。ここで、アプリ＃ｋのコンテキストの切替時間は、ユースケーステーブル４００内の「コンテキストコスト」に相当する。また、アプリ＃ｊとアプリ＃ｋとの切替回数の期待値は、ユースケーステーブル４００内の「期待値」に相当する。

より具体的には、例えば、第２の算出部５０６が、ユースケーステーブル４００を参照して、ＣＰＵ＃ｉに割り当てられているアプリ＃ｋのコンテキストコストと、アプリ＃ｋがアプリ＃ｊに切り替わる割合を示す期待値とを乗算して切替コストを算出する。ここで、上記切替コストは、ＣＰＵ＃ｉに割り当てられているアプリ＃ｋごとに算出される。

そこで、第２の算出部５０６は、ＣＰＵ＃ｉに割り当てられているアプリ＃ｋごとの切替コストを加算して、アプリ＃ｋごとの切替コストの合計を表すコスト（以下、「合計コストＳｉ」という）を算出することにしてもよい。なお、第２の算出部５０６の具体的な処理内容については、図７および図８を用いて後述する。

また、割当部５０４は、算出された各ＣＰＵ＃ｉのアプリ＃ｋごとの切替コストに基づいて、ＣＰＵ＃０〜ＣＰＵ＃ｎの中から、新たなアプリ＃ｊの割当先となるＣＰＵを選択する。具体的には、例えば、割当部５０４が、算出されたＣＰＵ＃０〜ＣＰＵ＃ｎごとの合計コストＳ０〜Ｓｎに基づいて、新たなアプリ＃ｊの割当先となるＣＰＵを選択することにしてもよい。

より具体的には、例えば、まず、割当部５０４が、ＣＰＵ＃０〜ＣＰＵ＃ｎごとの合計コストＳ０〜Ｓｎの中から、最小の合計コスト（以下、「合計コストＳ_min」という）を特定する。そして、割当部５０４が、ＣＰＵ＃０〜ＣＰＵ＃ｎの中から、合計コストＳ_minのＣＰＵ（以下、「ＣＰＵ＃Ｂ」という）を選択する。そして、割当部５０４は、選択したＣＰＵ＃Ｂにアプリ＃ｊを割り当てる。

これにより、新たに起動されたアプリ＃ｊの割り当てにともなって発生するアプリ間の切り替えにかかる負荷が最小となるＣＰＵ＃Ｂに、アプリ＃ｊを割り当てることができる。この結果、アプリ＃ｊ，＃ｋ間の切り替えが発生しにくく、たとえアプリ＃ｊ，＃ｋ間の切り替えが発生してもコンテキストスイッチにかかる時間が短いＣＰＵ＃Ｂにアプリ＃ｊを割り当てることができ、アプリ間の切り替えの高速化を図ることができる。

第３の算出部５０７は、新たに起動されたアプリ＃ｊと同時に実行され得るアプリ＃ｋと、ＣＰＵ＃ｉに割り当てられているアプリ＃ｍとを切り替えるときの切替コストを算出する。ここで、アプリ＃ｍは、例えば、アプリ＃ｋと同時に実行され得るアプリである。

具体的には、例えば、第３の算出部５０７が、アプリ＃ｊがＣＰＵ＃Ｂに割り当てられた結果、ＣＰＵ＃Ｂに割り当てられているアプリ＃ｋと、ＣＰＵ＃Ｂとは異なるＣＰＵ＃ｉに割り当てられているアプリ＃ｍとを切り替えるときの切替コストを算出する。

より具体的には、例えば、第３の算出部５０７が、ユースケーステーブル４００を参照して、ＣＰＵ＃ｉに割り当てられているアプリ＃ｍのコンテキストコストと、アプリ＃ｍがアプリ＃ｋに切り替わる割合を示す期待値とを乗算して切替コストを算出する。ここで、上記切替コストは、ＣＰＵ＃ｉ（ただし、ｉ≠Ｂ）に割り当てられているアプリ＃ｍごとに算出される。

そこで、第３の算出部５０７は、ＣＰＵ＃ｉに割り当てられているアプリ＃ｍごとの切替コストを加算して、アプリ＃ｍごとの切替コストの合計を表すコスト（以下、「合計コストＳ（ｉ）」という）を算出することにしてもよい。なお、第３の算出部５０７の具体的な処理内容については、図７および図９を用いて後述する。

また、割当部５０４は、算出された各ＣＰＵ＃ｉのアプリ＃ｍごとの切替コストに基づいて、ＣＰＵ＃０〜ＣＰＵ＃ｎの中から、ＣＰＵ＃Ｂに割り当てられているアプリ＃ｋの割当先となるＣＰＵを選択する。具体的には、例えば、割当部５０４が、算出されたＣＰＵ＃ｉの合計コストＳ（ｉ）に基づいて、ＣＰＵ＃Ｂに割り当てられているアプリ＃ｋの割当先となるＣＰＵを選択することにしてもよい。

より具体的には、例えば、ＣＰＵ＃ｉ（ただし、ｉ≠Ｂ）の合計コストＳ（ｉ）が、上述した合計コストＳ_min未満の場合、割当部５０４が、ＣＰＵ＃Ｂに割り当てられているアプリ＃ｋの割当先としてＣＰＵ＃ｉを選択する。そして、割当部５０４は、ＣＰＵ＃Ｂに割り当てられているアプリ＃ｋを、選択したＣＰＵ＃ｉに移行（いわゆる、マイグレーション）する。すなわち、アプリ＃ｋをＣＰＵ＃Ｂから他のＣＰＵに移行することで、アプリ間の切り替えにかかるシステム全体の負荷が少なくなる場合に、アプリ＃ｋのマイグレーションを行う。

これにより、新たに起動されたアプリ＃ｊと同時に実行され得るＣＰＵ＃Ｂのアプリ＃ｋを、アプリ＃ｋの割り当てにともなって発生するアプリ間の切り替えにかかる合計コストＳ（ｉ）が合計コストＳ_min未満のＣＰＵ＃ｉに割り当てることができる。この結果、各ＣＰＵ＃ｉにおけるアプリ間の切り替えにかかる負荷を最適化することができ、システム全体の性能を向上させることができる。

また、割当部５０４が、ＣＰＵ＃Ｂとは異なるＣＰＵのうち、算出された合計コストＳ（ｉ）が、最小かつ合計コストＳ_min未満のＣＰＵ＃ｉを、ＣＰＵ＃Ｂに割り当てられているアプリ＃ｋの割当先として選択することにしてもよい。これにより、各ＣＰＵ＃ｉにおけるアプリ間の切り替えにかかる負荷をより最適化することができ、システム全体の性能を向上させることができる。

なお、上述した説明では、第２の算出部５０６は、ＣＰＵ＃ｉに割り当てられているアプリ＃ｋのコンテキストコストと、アプリ＃ｋがアプリ＃ｊに切り替わる割合を示す期待値とを乗算して切替コストを算出することにしたが、これに限らない。例えば、第２の算出部５０６は、新たなアプリ＃ｊのコンテキストコストと、アプリ＃ｊがアプリ＃ｋに切り替わる割合を示す期待値とを乗算して切替コストを算出することにしてもよい。

また、上述した説明では、第３の算出部５０７は、ＣＰＵ＃ｉ（ｉ≠Ｂ）に割り当てられているアプリ＃ｍのコンテキストコストと、アプリ＃ｍがアプリ＃ｋに切り替わる割合を示す期待値とを乗算して切替コストを算出することにしたが、これに限らない。例えば、第３の算出部５０７は、ＣＰＵ＃ｉ（ｉ≠Ｂ）に割り当てられているアプリ＃ｋのコンテキストコストと、アプリ＃ｋがアプリ＃ｍに切り替わる割合を示す期待値とを乗算して切替コストを算出することにしてもよい。

（第２の算出部５０６の具体的な処理内容）
つぎに、図７および図８を用いて、第２の算出部５０６の具体的な処理内容について説明する。ここでは、実施の形態にかかるマルチコアプロセッサシステム３００の一例として、図１および図２に示したマルチコアプロセッサシステム１００を例に挙げて説明する（ｎ＝１）。

図７は、アプリケーションの割当例を示す説明図である。図７において、マルチコアプロセッサシステム１００内のＣＰＵ＃０にアプリ＃０，アプリ＃１およびアプリ＃２が割り当てられ、ＣＰＵ＃１にアプリ＃３およびアプリ＃４が割り当てられている。アプリ＃５は、新たに起動されたアプリである。

ここで、アプリ＃０〜アプリ＃４のうち、アプリ＃０，アプリ＃１，アプリ＃３およびアプリ＃４は、新たに起動されたアプリ＃５と同時に実行され得るアプリである。以下、ＣＰＵ＃０，ＣＰＵ＃１の合計コストＳ０，Ｓ１を算出する第２の算出部５０６の具体的な処理内容の一例について説明する。

・ＣＰＵ＃０の合計コストＳ０
まず、第２の算出部５０６は、ユースケーステーブル４００を参照して、ＣＰＵ＃０に割り当てられているアプリ＃０のコンテキストコスト『１００［ｕｓ］』と、アプリ＃０がアプリ＃５に切り替わる割合を示す期待値『０．５』とを乗算して切替コストを算出する。この結果、下記式（１）に示すように、切替コスト『５０［ｕｓ］』が算出される。

アプリ＃０：１００［ｕｓ］×０．５＝５０［ｕｓ］ ・・・（１）

つぎに、第２の算出部５０６は、ユースケーステーブル４００を参照して、ＣＰＵ＃０に割り当てられているアプリ＃１のコンテキストコスト『１［ｍｓ］』と、アプリ＃１がアプリ＃５に切り替わる割合を示す期待値『０．１』とを乗算して切替コストを算出する。この結果、下記式（２）に示すように、切替コスト『１００［ｕｓ］』が算出される。

アプリ＃１：１［ｍｓ］×０．１＝１００［ｕｓ］ ・・・（２）

そして、第２の算出部５０６は、ＣＰＵ＃０に割り当てられているアプリ＃０，アプリ＃１ごとの切替コストを加算して合計コストＳ０を算出する。ここでは、合計コストＳ０『１５０［ｕｓ］』が算出される。

・ＣＰＵ＃１の合計コストＳ１
まず、第２の算出部５０６は、ユースケーステーブル４００を参照して、ＣＰＵ＃１に割り当てられているアプリ＃３のコンテキストコスト『５００［ｕｓ］』と、アプリ＃３がアプリ＃５に切り替わる割合を示す期待値『０．２５』とを乗算して切替コストを算出する。この結果、下記式（３）に示すように、切替コスト『１２５［ｕｓ］』が算出される。

アプリ＃３：５００［ｕｓ］×０．２５＝１２５［ｕｓ］ ・・・（３）

つぎに、第２の算出部５０６は、ユースケーステーブル４００を参照して、ＣＰＵ＃１に割り当てられているアプリ＃４のコンテキストコスト『２５０［ｕｓ］』と、アプリ＃４がアプリ＃５に切り替わる割合を示す期待値『０．３』とを乗算して切替コストを算出する。この結果、下記式（４）に示すように、切替コスト『７５［ｕｓ］』が算出される。

アプリ＃４：２５０［ｕｓ］×０．３＝７５［ｕｓ］ ・・・（４）

そして、第２の算出部５０６は、ＣＰＵ＃１に割り当てられているアプリ＃３，アプリ＃４ごとの切替コストを加算して合計コストＳ１を算出する。ここでは、合計コストＳ１『２００［ｕｓ］』が算出される。

算出された合計コストＳ０，Ｓ１は、例えば、図８に示す割当先候補コストテーブル８００に記憶される。割当先候補コストテーブル８００は、例えば、１次キャッシュ３０１−１、２次キャッシュ３０３およびメモリ３０６などにより実現される。ここで、割当先候補コストテーブル８００について説明する。

図８は、割当先候補コストテーブルの記憶内容の一例を示す説明図である。図８において、割当先候補コストテーブル８００は、ＣＰＵ＃０，ＣＰＵ＃１ごとの合計コストＳ０，Ｓ１を記憶している。上記割当部５０４は、例えば、割当先候補コストテーブル８００を参照して、ＣＰＵ＃０およびＣＰＵ＃１のうち、合計コストＳｉが最小のＣＰＵ＃０にアプリ＃５を割り当てる。

（第３の算出部５０７の具体的な処理内容）
つぎに、図７および図９を用いて、第３の算出部５０７の具体的な処理内容について説明する。ここでは、アプリ＃５がＣＰＵ＃０に割り当てられた結果、ＣＰＵ＃０に割り当てられているアプリ＃０，アプリ＃１を、ＣＰＵ＃１にマイグレーション（移行）するか否かを判断する場合を例に挙げて説明する。

以下、ＣＰＵ＃０に割り当てられているアプリ＃０，アプリ＃１ごとに、ＣＰＵ＃１に割り当てられているアプリ＃ｍとの切り替えが行われるときの合計コストＳ（１）を算出する第３の算出部５０７の具体的な処理内容の一例について説明する。

・アプリ＃０の合計コストＳ（１）
まず、第３の算出部５０７は、ユースケーステーブル４００を参照して、ＣＰＵ＃１に割り当てられているアプリ＃３のコンテキストコスト『５００［ｕｓ］』と、アプリ＃３がアプリ＃０に切り替わる割合を示す期待値『０．４』とを乗算して切替コストを算出する。この結果、下記式（５）に示すように、切替コスト『２００［ｕｓ］』が算出される。

アプリ＃３：５００［ｕｓ］×０．４＝２００［ｕｓ］ ・・・（５）

つぎに、第３の算出部５０７は、ユースケーステーブル４００を参照して、ＣＰＵ＃１に割り当てられているアプリ＃４のコンテキストコスト『２５０［ｕｓ］』と、アプリ＃４がアプリ＃０に切り替わる割合を示す期待値『０．６』とを乗算して切替コストを算出する。この結果、下記式（６）に示すように、切替コスト『１５０［ｕｓ］』が算出される。

アプリ＃４：２５０［ｕｓ］×０．６＝１５０［ｕｓ］ ・・・（６）

そして、第３の算出部５０７は、ＣＰＵ＃１に割り当てられているアプリ＃３，アプリ＃４ごとの切替コストを加算して合計コストＳ（１）を算出する。ここでは、アプリ＃０の合計コストＳ（１）『３５０［ｕｓ］』が算出される。

・アプリ＃１の合計コストＳ（１）
まず、第３の算出部５０７は、ユースケーステーブル４００を参照して、ＣＰＵ＃１に割り当てられているアプリ＃３のコンテキストコスト『５００［ｕｓ］』と、アプリ＃３がアプリ＃１に切り替わる割合を示す期待値『０．５』とを乗算して切替コストを算出する。この結果、下記式（７）に示すように、切替コスト『２５０［ｕｓ］』が算出される。

アプリ＃３：５００［ｕｓ］×０．５＝２５０［ｕｓ］ ・・・（７）

つぎに、第３の算出部５０７は、ユースケーステーブル４００を参照して、ＣＰＵ＃１に割り当てられているアプリ＃４のコンテキストコスト『２５０［ｕｓ］』と、アプリ＃４がアプリ＃１に切り替わる割合を示す期待値『０．６』とを乗算して切替コストを算出する。この結果、下記式（８）に示すように、切替コスト『１５０［ｕｓ］』が算出される。

アプリ＃４：２５０［ｕｓ］×０．６＝１５０［ｕｓ］ ・・・（８）

そして、第３の算出部５０７は、ＣＰＵ＃１に割り当てられているアプリ＃３，アプリ＃４ごとの切替コストを加算して、アプリ＃１の合計コストＳ（１）を算出する。ここでは、合計コストＳ（１）『４００［ｕｓ］』が算出される。

算出されたアプリ＃０，アプリ＃１それぞれの合計コストＳ（１）は、例えば、図９に示すマイグレーション先候補コストテーブル９００に記憶される。マイグレーション先候補コストテーブル９００は、例えば、１次キャッシュ３０１−１、２次キャッシュ３０３およびメモリ３０６などにより実現される。ここで、マイグレーション先候補コストテーブル９００について説明する。

図９は、マイグレーション先候補コストテーブルの記憶内容の一例を示す説明図である。図９において、マイグレーション先候補コストテーブル９００は、ＣＰＵ＃０に割り当てられているアプリ＃０，アプリ＃１をＣＰＵ＃１に移行する場合のそれぞれの合計コストＳ（１）を記憶している。

上記割当部５０４は、マイグレーション先候補コストテーブル９００を参照して、ＣＰＵ＃０に割り当てられているアプリ＃０の割当先となるＣＰＵを選択することにしてもよい。ここで、合計コストＳ_minは、上述した合計コストＳ０『１５０［ｕｓ］』である。このため、アプリ＃０の合計コストＳ（１）『３５０［ｕｓ］』は、合計コストＳ_minより大きい。この場合、割当部５０４は、ＣＰＵ＃０に割り当てられているアプリ＃０の割当先を変更しない。すなわち、アプリ＃０のマイグレーションは行われない。

また、割当部５０４は、マイグレーション先候補コストテーブル９００を参照して、ＣＰＵ＃０に割り当てられているアプリ＃１の割当先となるＣＰＵを選択する。ここで、アプリ＃１の合計コストＳ（１）『４００［ｕｓ］』は、合計コストＳ_minより大きい。この場合、割当部５０４は、ＣＰＵ＃０に割り当てられているアプリ＃１の割当先を変更しない。すなわち、アプリ＃１のマイグレーションは行われない。

（スケジューラ１０１によるスケジューリング処理手順）
つぎに、実施の形態にかかるスケジューラ１０１によるスケジューリング処理手順について説明する。

図１０および図１１は、実施の形態にかかるスケジューラによるスケジューリング処理手順の一例を示すフローチャートである。図１０のフローチャートにおいて、まず、受付部５０１により、新たなアプリ＃ｊの起動通知を受け付けたか否かを判断する（ステップＳ１００１）。

ここで、新たなアプリ＃ｊの起動通知を受け付けるのを待って（ステップＳ１００１：Ｎｏ）、受け付けた場合（ステップＳ１００１：Ｙｅｓ）、特定部５０２により、ユースケーステーブル４００を参照して、起動通知が受け付けられたアプリ＃ｊと同時に実行され得るアプリ＃ｋを特定する（ステップＳ１００２）。

つぎに、検出部５０３により、マルチコアプロセッサシステム３００内のＣＰＵ＃０〜ＣＰＵ＃ｎの中から、新たなアプリ＃ｊと同時に実行され得るアプリ＃ｋが割り当てられていないＣＰＵを検出する（ステップＳ１００３）。

このあと、割当部５０４により、新たなアプリ＃ｊと同時に実行され得るアプリ＃ｋが割り当てられていないＣＰＵが検出されたか否かを判断する（ステップＳ１００４）。ここで、ＣＰＵが検出されなかった場合（ステップＳ１００４：Ｎｏ）、図１１に示すステップＳ１１０１に移行する。

一方、ＣＰＵが検出された場合（ステップＳ１００４：Ｙｅｓ）、割当部５０４により、複数のＣＰＵが検出されたか否かを判断する（ステップＳ１００５）。ここで、複数のＣＰＵが検出されなかった場合（ステップＳ１００５：Ｎｏ）、割当部５０４により、検出されたＣＰＵ＃Ａにアプリ＃ｊを割り当てて（ステップＳ１００６）、本フローチャートによる一連の処理を終了する。

一方、複数のＣＰＵが検出された場合（ステップＳ１００５：Ｙｅｓ）、第１の算出部５０５により、検出された各ＣＰＵの負荷を算出する（ステップＳ１００７）。そして、割当部５０４により、検出された複数のＣＰＵの中から、算出された負荷が最小となるＣＰＵ＃Ａにアプリ＃ｊを割り当てて（ステップＳ１００８）、本フローチャートによる一連の処理を終了する。

図１１のフローチャートにおいて、まず、第２の算出部５０６により、ＣＰＵ＃ｉの「ｉ」を「ｉ＝０」とする（ステップＳ１１０１）。そして、第２の算出部５０６により、ＣＰＵ＃０〜ＣＰＵ＃ｎの中からＣＰＵ＃ｉを選択する（ステップＳ１１０２）。つぎに、第２の算出部５０６により、ＣＰＵ＃ｉに割り当てられているアプリの中からアプリ＃ｋを選択する（ステップＳ１１０３）。

このあと、第２の算出部５０６により、新たなアプリ＃ｊと、選択したアプリ＃ｋとを切り替えるときの切替コストを算出する（ステップＳ１１０４）。そして、第２の算出部５０６により、ＣＰＵ＃ｉに割り当てられているアプリの中から選択されていない未選択のアプリ＃ｋがあるか否かを判断する（ステップＳ１１０５）。

ここで、未選択のアプリ＃ｋがある場合（ステップＳ１１０５：Ｙｅｓ）、ステップＳ１１０３に戻る。一方、未選択のアプリ＃ｋがない場合（ステップＳ１１０５：Ｎｏ）、第２の算出部５０６により、算出したアプリ＃ｋごとの切替コストの合計を表す合計コストＳｉを算出する（ステップＳ１１０６）。

つぎに、第２の算出部５０６により、ＣＰＵ＃ｉの「ｉ」をインクリメントして（ステップＳ１１０７）、「ｉ」が「ｎ」より大きいか否かを判断する（ステップＳ１１０８）。ここで、「ｉ」が「ｎ」以下の場合（ステップＳ１１０８：Ｎｏ）、ステップＳ１１０２に戻る。

一方、「ｉ」が「ｎ」より大きい場合（ステップＳ１１０８：Ｙｅｓ）、割当部５０４により、ＣＰＵ＃０〜ＣＰＵ＃ｎごとの合計コストＳ０〜Ｓｎの中から、最小の合計コストＳ_minを特定する（ステップＳ１１０９）。そして、割当部５０４により、ＣＰＵ＃０〜ＣＰＵ＃ｎのうち合計コストＳ_minのＣＰＵ＃Ｂにアプリ＃ｊを割り当てる（ステップＳ１１１０）。

最後、割当部５０４により、ＣＰＵ＃Ｂに割り当てられているアプリ＃ｋのマイグレーション処理を実行して（ステップＳ１１１１）、本フローチャートによる一連の処理を終了する。

これにより、新たなアプリ＃ｊを、同時に実行される可能性が高いアプリ＃ｋが割り当てられていないＣＰＵ＃Ａに割り当てることができる。また、ＣＰＵ＃Ａが存在しない場合は、新たに起動されたアプリ＃ｊの割り当てにともなって発生するアプリ間の切り替えにかかる負荷が最小となるＣＰＵ＃Ｂに、アプリ＃ｊを割り当てることができる。

つぎに、図１１に示したステップＳ１１１１のマイグレーション処理の具体的な処理手順について説明する。

図１２は、マイグレーション処理の具体的処理手順の一例を示すフローチャートである。図１２において、まず、第３の算出部５０７により、ＣＰＵ＃Ｂに割り当てられているアプリの中からアプリ＃ｋを選択する（ステップＳ１２０１）。このあと、第３の算出部５０７により、ユースケーステーブル４００を参照して、アプリ＃ｋと同時に実行され得るアプリ＃ｍを特定する（ステップＳ１２０２）。

つぎに、第３の算出部５０７により、ＣＰＵ＃ｉの「ｉ」を「ｉ＝０」とする（ステップＳ１２０３）。そして、第３の算出部５０７により、ＣＰＵ＃ｉの「ｉ」がＣＰＵ＃Ｂの「Ｂ」と同じか否かを判断する（ステップＳ１２０４）。ここで、ＣＰＵ＃ｉの「ｉ」がＣＰＵ＃Ｂの「Ｂ」と同じ場合（ステップＳ１２０４：Ｙｅｓ）、ステップＳ１２１１に移行する。

一方、ＣＰＵ＃ｉの「ｉ」がＣＰＵ＃Ｂの「Ｂ」と違う場合（ステップＳ１２０４：Ｎｏ）、第３の算出部５０７により、ＣＰＵ＃０〜ＣＰＵ＃ｎの中からＣＰＵ＃ｉを選択する（ステップＳ１２０５）。そして、第３の算出部５０７により、ＣＰＵ＃ｉに割り当てられているアプリの中からアプリ＃ｍを選択する（ステップＳ１２０６）。

つぎに、第３の算出部５０７により、アプリ＃ｋと、選択したアプリ＃ｍとを切り替えるときの切替コストを算出する（ステップＳ１２０７）。そして、第３の算出部５０７により、ＣＰＵ＃ｉに割り当てられているアプリの中から選択されていない未選択のアプリ＃ｍがあるか否かを判断する（ステップＳ１２０８）。

ここで、未選択のアプリ＃ｍがある場合（ステップＳ１２０８：Ｙｅｓ）、ステップＳ１２０６に戻る。一方、未選択のアプリ＃ｍがない場合（ステップＳ１２０８：Ｎｏ）、第３の算出部５０７により、算出したアプリ＃ｍごとの切替コストの合計を表す合計コストＳ（ｉ）を算出する（ステップＳ１２０９）。

そして、割当部５０４により、ＣＰＵ＃ｉの合計コストＳ（ｉ）が、図１１に示したステップＳ１１０９において特定された合計コストＳ_min未満となるか否かを判断する（ステップＳ１２１０）。ここで、ＣＰＵ＃ｉの合計コストＳ（ｉ）が合計コストＳ_min以上の場合（ステップＳ１２１０：Ｎｏ）、第３の算出部５０７により、ＣＰＵ＃ｉの「ｉ」をインクリメントして（ステップＳ１２１１）、「ｉ」が「ｎ」より大きいか否かを判断する（ステップＳ１２１２）。

ここで、「ｉ」が「ｎ」以下の場合（ステップＳ１２１２：Ｎｏ）、ステップＳ１２０４に戻る。一方、「ｉ」が「ｎ」より大きい場合（ステップＳ１２１２：Ｙｅｓ）、ステップＳ１２１４に移行する。

また、ステップＳ１２１０において、ＣＰＵ＃ｉの合計コストＳ（ｉ）が合計コストＳ_min未満の場合（ステップＳ１２１０：Ｙｅｓ）、割当部５０４により、ＣＰＵ＃Ｂに割り当てられているアプリ＃ｋをＣＰＵ＃ｉに移行する（ステップＳ１２１３）。

そして、第３の算出部５０７により、ＣＰＵ＃Ｂに割り当てられているアプリの中から選択されていない未選択のアプリ＃ｋがあるか否かを判断する（ステップＳ１２１４）。ここで、未選択のアプリ＃ｋがある場合（ステップＳ１２１４：Ｙｅｓ）、ステップＳ１２０１に戻る。一方、未選択のアプリ＃ｋがない場合（ステップＳ１２１４：Ｎｏ）、本フローチャートによる一連の処理を終了する。

これにより、新たに起動されたアプリ＃ｊと同時に実行され得るＣＰＵ＃Ｂのアプリ＃ｋを、アプリ＃ｋの割り当てにともなって発生するアプリ間の切り替えにかかる負荷が最小となる他のＣＰＵに割り当てることができる。

以上説明したように、実施の形態にかかるスケジューラ１０１によれば、新たなアプリ＃ｊを、同時に実行される可能性が高いアプリ＃ｋが割り当てられていないＣＰＵ＃Ａに割り当てることができる。この結果、アプリ＃ｊとアプリ＃ｋとの切り替えが発生した際に、アプリ＃ｊ，アプリ＃ｋのコンテキスト情報の退避やロードが不要となるため、アプリ間の切り替えを高速に行うことができる。

また、スケジューラ１０１によれば、新たなアプリ＃ｊを、同時に実行される可能性が高いアプリ＃ｋが割り当てられていないＣＰＵのうち、負荷が最小のＣＰＵ＃Ａに割り当てることができる。この結果、アプリ間の切り替えを高速に行うとともに、ＣＰＵ＃０〜ＣＰＵ＃ｎに負荷を分散してシステム全体の性能を向上させることができる。

また、スケジューラ１０１によれば、ＣＰＵ＃Ａが存在しない場合は、新たに起動されたアプリ＃ｊの割り当てにともなって発生するアプリ間の切り替えにかかる負荷が最小となるＣＰＵ＃Ｂに、アプリ＃ｊを割り当てることができる。この結果、アプリ＃ｊ，＃ｋ間の切り替えが発生しにくく、また、たとえアプリ＃ｊ，＃ｋ間の切り替えが発生してもコンテキストスイッチにかかる時間が短いＣＰＵ＃Ｂにアプリ＃ｊを割り当てることができ、アプリ間の切り替えの高速化を図ることができる。

また、スケジューラ１０１によれば、新たに起動されたアプリ＃ｊと同時に実行され得るＣＰＵ＃Ｂのアプリ＃ｋを、アプリ＃ｋの移行にともなって発生するアプリ間の切り替えにかかる合計コストＳ（ｉ）が合計コストＳ_min未満のＣＰＵ＃ｉに移行することができる。この結果、各ＣＰＵ＃ｉにおけるアプリ間の切り替えにかかる負荷を最適化することができ、システム全体の性能を向上させることができる。

また、スケジューラ１０１によれば、ＣＰＵ＃Ｂのアプリ＃ｋを、アプリ＃ｋの移行にともなって発生するアプリ間の切り替えにかかる合計コストＳ（ｉ）が最小かつ合計コストＳ_min未満のＣＰＵ＃ｉに移行することができる。これにより、各ＣＰＵ＃ｉにおけるアプリ間の切り替えにかかる負荷をより最適化することができ、システム全体の性能を向上させることができる。

これらのことから、本スケジューリング方法およびスケジューリングシステムによれば、高性能化および低消費電力化とともに、アプリケーションの切り替えの高速化を図ることができる。

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

１００，３００ マルチコアプロセッサシステム
１０１ スケジューラ
１０２ アプリケーション情報テーブル
４００ ユースケーステーブル
５０１ 受付部
５０２ 特定部
５０３ 検出部
５０４ 割当部
５０５ 第１の算出部
５０６ 第２の算出部
５０７ 第３の算出部
６００ 割当テーブル
８００ 割当先候補コストテーブル
９００ マイグレーション先候補コストテーブル

Claims (10)

1. 複数のプロセッサを管理するスケジューラが、
   第１アプリケーションが起動されたときに、アプリケーション情報テーブルに基づいて、前記第１アプリケーションと同時に実行されることのない第２アプリケーションを実行するプロセッサを検出し、
   前記プロセッサに前記第１アプリケーションを割り当てること
   を特徴とするスケジューリング方法。
2. 前記アプリケーション情報テーブルは、
   アプリケーション毎に、前記アプリケーションのコンテキスト情報と、前記アプリケーションと同時に実行され得る他のアプリケーション情報とを含むこと
   を特徴とする請求項１に記載のスケジューリング方法。
3. 前記第１アプリケーションと同時に実行されることのない第２アプリケーションを実行するプロセッサが複数あるときに、前記複数のプロセッサから負荷が最小であるプロセッサが前記第１アプリケーションに割り当てられること
   を特徴とする請求項１に記載のスケジューリング方法。
4. 複数のプロセッサを管理するスケジューラが、
   第１アプリケーションが起動されたときに、アプリケーション情報テーブルに基づいて、前記複数のプロセッサの少なくとも一のプロセッサで実行される第２アプリケーションを前記第１アプリケーションに切り替えるときの負荷を計算し、
   前記負荷に基づいて前記第１アプリケーションを実行する第１プロセッサを選択すること
   を特徴とするスケジューリング方法。
5. 前記第２アプリケーションは、前記第１アプリケーションと同時に実行され得ること
   を特徴とする請求項４に記載のスケジューリング方法。
6. 前記アプリケーション情報テーブルは、
   アプリケーション毎に、前記アプリケーションのコンテキスト情報と、前記アプリケーションと同時に実行され得る他のアプリケーション情報とを含むこと
   を特徴とする請求項４または請求項５に記載のスケジューリング方法。
7. 前記負荷は、前記第２アプリケーションのコンテキストの切り替え時間と、前記第２アプリケーションと前記第１アプリケーションとの切り替え回数の期待値とに基づいて算出されること
   を特徴とする請求項４乃至請求項６の何れか一に記載のスケジューリング方法。
8. 前記少なくとも一のプロセッサは２個以上のプロセッサであり、
   前記２個以上のプロセッサで実行される第２アプリケーションを前記第１アプリケーションに切り替えるときの負荷を計算し、
   複数の前記負荷の中で最小の負荷を有するプロセッサを前記第１プロセッサとして選択すること
   を特徴とする請求項４乃至請求項７の何れか一に記載のスケジューリング方法。
9. 前記アプリケーション情報テーブルに基づいて、前記複数のプロセッサの少なくとも一のプロセッサで実行される第３アプリケーションを前記第２アプリケーションに切り替えるときの負荷を計算し、
   前記負荷に基づいて前記第２アプリケーションを実行する第２プロセッサを選択すること
   を特徴とする請求項４乃至請求項８の何れか一に記載のスケジューリング方法。
10. 複数のプロセッサと、
    前記複数のプロセッサを管理するスケジューラと、
    を含み、
    前記スケジューラは、
    第１アプリケーションの起動タスクを受信したときに、アプリケーション情報テーブルに基づいて、前記複数のプロセッサの少なくとも一のプロセッサで実行される第２アプリケーションを前記第１アプリケーションに切り替えるときの負荷を計算し、
    前記負荷に基づいて前記第１アプリケーションを実行する第１プロセッサを選択すること
    を特徴とするスケジューリングシステム。

Images