JP4298679B2 - 情報処理方法、情報処理装置、およびサーバ - Google Patents

Description

本発明は情報処理技術に関し、特にオペレーティングシステムによって複数のタスク処理を制御する情報処理装置と、その装置における情報処理方法、およびその装置を支援するサーバに関する。

近年の著しい技術進歩に伴い、テレビ、コンピュータゲーム、ディジタルビデオ、電子メールなどを含む複数の機能を、一の装置で並行して実行することのできるコンピュータが広く一般に浸透しつつある。そのようなコンピュータの実現において根幹をなす技術的課題のひとつが処理の高速化である。処理の高速化は、コンピュータを構成する各モジュールにおける処理速度の向上以外に、それらのモジュールが供給する量的、時間的資源を効率的に使用することによってももたらされる。例えば演算処理を高速化するためにマルチプロセッサによる並列処理を行ったり、アプリケーションソフトウェアやユーティリティソフトウェアなどのソフトウェアが使用する関数をコンポーネントとして別に保持し、必要に応じてロードすることによって効率的な処理を行ったりする。

上記のコンポーネントや、ソフトウェア本体、基本ソフトウェアであるオペレーティングシステム（以下、ＯＳと呼ぶ）などの技術開発は日々進捗しており、ユーザは自らのコンピュータの性能向上を求めて、それらを最新バージョンへと更新しようと望む。しかしながらソフトウェアは通常、ソフトウェア本体の他、コンポーネントやＯＳ、および装置との協働によって実現されるものであるため、個々にバージョンアップを行うことによって互換性がなくなり、ソフトウェアの動作に不具合が生じることがある。そこでコンポーネントにバージョン互換性を記述したファイルを付加しておき、互換性を別に管理することによってバージョンアップを効率化し、かつ不具合が発生しないようにする技術が提案されている（例えば特許文献１参照）。
特開２００１−３３１３２４号公報

演算の並列処理など装置自体の進歩や、上述のような機能の分業などの工夫により可能となった複数のソフトウェアの並行処理においては、コンピュータに含まれるプロセッサ、メモリ、およびバスなどの資源を、複数のソフトウェアで共有する必要がある。このため、起動するソフトウェアの数が増加するほど、一のソフトウェアが占有できる資源が減少し、処理の順番待ちなどによって動作速度が低下する。しかし、ソフトウェアによってはある動作速度を確保できないと、正常な動作を確保できない場合があることを、本発明者は認識した。

本発明はこのような課題に鑑みてなされたものであり、その目的は複数のソフトウェアを正常かつ効率的に動作させる技術の提供にある。

本発明のある態様は情報処理方法に関する。この情報処理方法は、新規タスクの実行要求を受け付けるステップと、新規タスクの所要処理時間および新規タスクの処理における所要バス帯域の少なくとも一方を特定するステップと、複数のタスクに関する処理手順を表すスケジューラに予約された予約済みタスクと、新規タスクの所要処理時間とを合計した総所要処理時間と、それらのタスクを実行する装置が確保できる処理時間との比較、および、予約済みタスクと新規タスクの処理における所要バス帯域とを合計した総所要バス帯域と、それらのタスクを実行する装置が確保できるバス帯域との比較、の少なくとも一方を行うステップと、比較結果に基づき新規タスクの実行可否を判定するステップと、新規タスクが実行可能と判定された場合、その新規タスクをスケジューラに予約するステップと、スケジューラに基づき実行可能と判定された新規タスクを含むタスクの処理を行うステップと、を含むことを特徴とする。ここで実行可否を判定するステップは、新規タスクの優先度情報を取得するステップを含み、取得した優先度情報に基づいて実行可否を判定する。

「タスク」とは、ある目的を達成するためにプログラムされたアプリケーションまたはそれに含まれる情報処理の内容をいい、アプリケーションと対応してもよいし、入出力制御やユーザが指定したコマンドなどアプリケーションよりも小さい単位と対応してもよく、何らかの処理または機能の単位に対応すればよい。

本発明の別の態様は情報処理装置に関する。この情報処理装置は、主に装置全体を統括的に制御する第一のプロセッサと、主に演算処理を行う第二のプロセッサと、処理するタスクに関する情報を記憶するメインメモリと、外部装置とのデータ入出力を制御するデータ入出力プロセッサと、を備える情報処理装置であって、第一のプロセッサは、新規タスクの実行要求を受け付ける実行要求受付け部と、新規タスクの処理に係る時間関連パラメータを特定するパラメータ特定部と、特定した時間関連パラメータと、情報処理装置の内部に係る情報のうち時間関連パラメータと対応する対応内部情報と、に基づき新規タスクの実行可否を判定する実行許可部と、新規タスクが実行可能と判定された場合、新規タスクの処理を起動する起動処理部と、を備え、時間関連パラメータは、第一のプロセッサとメインメモリ間のデータ転送において新規タスクが必要とするバス帯域、第一のプロセッサと第二のプロセッサ間のデータ転送において新規タスクが必要とするバス帯域、および第一のプロセッサとデータ入出力プロセッサ間のデータ転送において新規タスクが必要とするバス帯域のうち、少なくともひとつを含むことを特徴とする。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、複数のタスクの正常な動作の保障を効率的に実現できる。

実施の形態の概要
複数のソフトウェアを同時に実行する情報処理装置においては、プロセッサによる処理時間やデータ転送に使用されるバス帯域などの有限な資源をいかに各ソフトウェアに割り振るかが重要な問題である。例えば、すでに複数のソフトウェアが動作している装置で、新たにソフトウェアを起動した場合、動作するソフトウェアで均等に処理時間やバス帯域を割り振れば、各ソフトウェアの動作は当然遅くなる。しかし、グラフィック処理などリアルタイム性を要求されるタスクを含むソフトウェアでは、一定以上の処理速度を確保できないと正常な動作が保障されない場合がある。本実施の形態では、処理速度に対し重要となる、プロセッサの占有時間（以後、処理時間と呼ぶ）やバス帯域を、タスクの起動時に確認することにより、起動するタスクおよび起動済みのタスクのいずれにおいても、ユーザの期待しない動作速度での処理や不具合の発生を抑制する。より具体的には以下のような処理を行う。

１．まず新規ソフトウェアの実行要求を受け付けた際、対応するタスク（以後、新規タスクと呼ぶ）が必要とする処理時間、または必要とするバス帯域の少なくとも一方を特定する。それらの値は、新規ソフトウェアのソースプログラムに付加されたり、ネットワークを介してサーバより取得したりする属性ファイル中、処理時間属性、バス帯域属性にそれぞれ記述されている。さらに、すでに起動しているタスク（以後、予約済みタスクと呼ぶ）が必要とする処理時間、または必要とするバス帯域を特定する。それらの値は、メインメモリに格納したスケジュールファイル、バス帯域予約ファイルに、タスクごとに記述されている。続いて、新規タスクが必要とする処理時間と、予約済みタスクの処理時間から計算されるプロセッサの空き時間との比較、および新規タスクが必要とするバス帯域と、予約済みタスクの使用バス帯域から計算されるバス帯域の空きとの比較、の少なくとも一方を行い、新規タスクが処理時間、バス帯域の少なくともいずれかの観点から、実行可能かどうかを判定する。実行可能と判定された場合は、スケジュールファイル、バス帯域予約ファイルを更新し、新規タスクを起動させ、スケジュールファイルに基づき処理を行う。実行可否判断には各タスクの優先度を考慮してもよい。新規タスクの優先度は優先度属性としてソースプログラムなどに付加される。予約済みタスクの優先度は、メインメモリなどに格納した優先度ファイルに、タスクごとに記述されている（実施の形態１〜８）。

２．新規タスクが必要とする処理時間がプロセッサの空き時間より大きい場合、または、必要とするバス帯域がバス帯域の空きより大きい場合、優先度に基づいて予約済みタスクの停止の可否も判定する（実施の形態４、５）。

３．新規タスクが必要とするバス帯域がバス帯域の空きより大きい場合、優先度に基づいて各タスクが使用するバス帯域を調整する（実施の形態５）。

４．新規タスクが実行不可と判定された場合は、当該タスクの実行要求を起こしたタスクに対し、その旨を通知する（実施の形態１〜５）。

５．新規タスクの実行不可や、予約済みタスクの停止が判定されたときは、装置を制御するメインプロセッサがそれを認識し、ユーザへその旨を通知する（実施の形態１〜５）。

実施の形態１
図１は、本実施の形態における情報処理装置１０００の構成を示すブロック図である。情報処理装置１０００は、グラフィックプロセッサ１００、メインプロセッサ２００、入出力プロセッサ６５０、およびメインメモリ５０を含み、それらはバス４０によって相互に接続されている。入出力プロセッサ６５０は、表示装置５００および記憶装置６００と接続されている。

図１において、様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされた予約管理機能のあるプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

この情報処理装置１０００では、情報処理装置１０００を効率よく使用するための機能、環境を提供し、装置全体を統括的に制御するＯＳが実行される。そのＯＳによって情報処理装置１０００の各機能ブロックが動作することにより、複数のソフトウェアが実行される。

メインプロセッサ２００は、複数のサブプロセッサ３０と管理プロセッサ３２を含む。管理プロセッサ３２は、複数のソフトウェアに対応するタスクを時分割し、タイムスライスごとにサブプロセッサ３０に割り当て、それをメインメモリ５０に格納したスケジュールファイルに書き込む。さらにバス４０の帯域を、バス帯域予約ファイルをもとに複数のタスクに割り振り、ハードウェアとの協働により使用バス帯域の制御を行う。サブプロセッサ３０は、スケジュールファイルに則りタスクの並列処理を行う。

グラフィックプロセッサ１００は、グラフィックメモリ１０および処理ユニット１２を含む。メインプロセッサ２００により処理されるそれぞれのタスクに関連する画像処理を処理ユニット１２が行い、生成された画像、映像は一旦グラフィックメモリ１０に格納され、入出力プロセッサ６５０の制御により表示装置５００または記憶装置６００に出力される。

メインメモリ５０は、主にメインプロセッサ２００によって使用される記憶領域である。このメインメモリ５０は、ロードされたソフトウェアのプログラムや、ソフトウェアに対応するタスクに関連するデータが格納される。また、予約済みタスクのスケジュールファイル、バス帯域予約ファイル、優先度ファイルもメインメモリ５０に格納される。

表示装置５００はメインプロセッサ２００およびグラフィックプロセッサ１００の処理の結果得られた画像、映像を出力する。記憶装置６００はハードディスク装置、ＣＤ−ＲＯＭ、ＭＯ、半導体の記憶素子などの外部記憶装置のいずれか、またはそれらの組み合わせでよい。情報処理装置１０００はＯＳの制御のもと、記憶装置６００に記憶されたソフトウェアをメインメモリ５０に読み出すことにより、当該ソフトウェアのロードを行い、タスクの処理を実行する。入出力プロセッサ６５０は表示装置５００や記憶装置６００と情報処理装置１０００との上述のようなデータの入出力を制御する。

なお図１において、バス４０は簡単のために一の線で示されているが、実際には複数のバスで構成してよく、所定の機能ブロック間に専用バスを設けてよい。

図２は、本実施の形態における管理プロセッサ３２の構成を示すブロック図である。管理プロセッサ３２は、ユーザが記憶装置６００に格納されたソフトウェアを情報処理装置１０００に認識させることによって行う、ソフトウェアのロード要求を受け付けるロード要求受付部６０と、ロード要求を受け付けた新規ソフトウェアの属性ファイルを記憶装置６００より読み出し、新規タスクの所要処理時間を取得する属性取得部６２と、スケジュールファイルをメインメモリ５０より読み出し、予約済みタスクの所要処理時間を取得する状況取得部６４と、新規タスクの所要処理時間とプロセッサの空き時間を比較し、新規タスクの処理を実行できるか否か判定する判定部６６と、実行可能と判定された新規ソフトウェアのプログラムを記憶装置６００より読み出し、メインメモリ５０へ格納し、新規タスクをサブプロセッサ３０に割り当て、スケジュールファイルを更新する起動処理部６８と、を含む。起動処理部６８は、新規ソフトウェアのロードが実行不可とされたときも、新規ソフトウェアを格納した記憶装置６００へロード要求拒否の信号を送信し、入出力プロセッサ６５０を介して表示装置５００へロード不可の通知を表示するなどのロード不許可処理を行う。

図３は本実施の形態における記憶装置６００の構成を模式的に示している。本実施の形態では、属性ファイルがソフトウェア本体であるプログラムファイルや各種コンポーネントなどとともに記憶装置６００に格納される。

図４は本実施の形態における属性ファイルのデータ構造の例を示している。属性テーブル７０は、属性名称欄７０ａ、および必要値欄７０ｂを含む。ここでは、「処理時間」属性に対し、タスクの処理に必要な処理時間が必要値欄７０ｂに記述されている。図４における処理時間属性の必要値は、所定単位時間に対して当該タスクがサブプロセッサ３０を占有する時間の絶対値として表現されているが、これについては後述する。処理時間の必要値はソフトウェアの出荷時にソフトウェアメーカによって設定される値であり、過負荷での検証実験などによって得られた値を採用する。

属性は処理時間属性の他、実行許可属性やメモリ容量属性を含んでもよい。実行許可属性は例えば、ドングルの接続やシリアルナンバーの入力など、実行に必要な条件を、メモリ容量属性はタスクの処理に必要なメモリ容量を表す。

次に上述した構成による動作を説明する。図５、図６および図７は、主に管理プロセッサ３２によって行われるソフトウェアのロードに係る処理手順を示す。まず図５において、ユーザはゲームなど所望の新規ソフトウェアを記憶したＣＤ−ＲＯＭを情報処理装置１０００に接続された読み取り装置へ挿入するなどして、情報処理装置１０００に対し新規ソフトウェアのロード要求を行い、管理プロセッサ３２のロード要求受付部６０はそれを受信する（Ｓ１０）。なお、新規ソフトウェアが格納された記憶装置６００は、ＣＤ−ＲＯＭに限られず、ハードディスク装置、ＭＯ、半導体の記憶素子などの記憶装置でもよい。さらに、図示しないネットワークに接続されたサーバから、所望の新規ソフトウェアを情報処理装置１０００にダウンロードするように要求する構成としてもよい。ここでは記憶装置６００としてＣＤ−ＲＯＭを例に説明する。

ロード要求受付部６０がロード要求を受け付けると、属性取得部６２は、新規ソフトウェアのＣＤ−ＲＯＭに記憶された属性ファイルに含まれる、実行許可属性やメモリ容量属性など一般的な属性を取得する。次いで状況取得部６４がそれぞれの属性の実態を確認し、判定部６６がそれぞれの属性の条件を実態が満足しているかを判定する（Ｓ１２）。条件を満たしていないと判定された場合は（Ｓ１２のＮ）、起動処理部６８が上述のロード不許可処理を行い（Ｓ１４）、シーケンスを終了する。

一方、条件を満たしていると判定された場合（Ｓ１２のＹ）、図６示すように、属性取得部６２は属性ファイル内の処理時間属性を検出し、必要値を読み込む（Ｓ３０）。次いで状況取得部６４はスケジュールファイルをメインメモリ５０より読み込み、予約済みタスクの割り当て状況からサブプロセッサ３０の空き時間を導出する（Ｓ３２）。そして判定部６６は、処理時間の必要値と、サブプロセッサ３０の空き時間とを比較する（Ｓ３４）。比較の結果、処理時間の必要値がサブプロセッサ３０の空き時間を上回っていると判定された場合は（Ｓ３４のＮ）、起動処理部６８がロード不許可処理を行い（Ｓ３７）、シーケンスを終了する。

一方、処理時間の必要値がサブプロセッサ３０の空き時間を超えないと判定された場合は（Ｓ３４のＹ）、図７のごとく、起動処理部６８により新規ソフトウェアの本体をＣＤ−ＲＯＭからメインメモリ５０へ読み出し、ロードを完了する（Ｓ３８）。さらに起動処理部６８は、新規タスクを時分割し、タイムスライスごとにサブプロセッサ３０に割り当て、メインメモリ５０に格納されたスケジュールファイルを更新する（Ｓ４０）。これにより、上述のとおりサブプロセッサ３０による新規タスクの処理が開始される。

次に処理時間属性について説明する。図８は本実施の形態におけるスケジュールファイルに記述されるタスクの割り当て状況の例を模式的に示している。同図は、２つの予約済みソフトウェア、ソフトウェアＡおよびソフトウェアＢにそれぞれ対応するタスクＡおよびタスクＢが時分割され、あらかじめ設定された単位期間においてそれらのタスクが順番に処理されるように複数のサブプロセッサ３０ａ〜３０ｄに割り当てられた様子を示している。この単位期間内の処理を繰り返すことにより、タスクＡ、タスクＢの実行が進捗する。

本実施の形態においてＳ３０で読み込まれる処理時間属性の必要値は、この単位期間のうち、タスクが必要とする処理時間の絶対値で表現する。図８の例では、ソフトウェアＡおよびソフトウェアＢの処理時間属性の必要値はそれぞれ単位期間の２０％、および４０％であるから、単位期間が例えば１６．６ｍｓであるとすると、３．３ｍｓ、６．６ｍｓと記述されていることになる。そしてそれらのソフトウェアが実行可能と判定されロードされたときに、Ｓ４０にてスケジュールファイルにそれらの値が書き込まれ、各サブプロセッサ３０によってタスクの処理がなされる。

ここでユーザが、処理時間属性の必要値が単位期間の５０％である新規ソフトウェアＣのロード要求を行ったとする。図８で示された予約済みソフトウェアＡおよびＢの占有割合の合計が６０％であるため、状況取得部６４がＳ３２で導出するサブプロセッサ３０の空き時間は割合にして４０％である。したがって判定部６６はＳ３４において、ソフトウェアＣの処理時間属性の必要値がサブプロセッサ３０の空き時間を上回っていると判定し、ソフトウェアＣのロードは行われない。一方、ソフトウェアＣの処理時間属性の必要値が単位期間の３０％を示していた場合は、サブプロセッサ３０の空き時間を超えないと判定され、ソフトウェアＣがロードされる。

上述の場合、管理プロセッサ３２の処理を制御するＯＳにおいてあらかじめ単位期間を設定しておき、各ソフトウェアは同一の単位期間に対してそれぞれのタスクに必要な処理時間の絶対値を処理時間属性の必要値として保持する。単位期間としては例えば、表示装置５００の垂直同期信号の周期を設定する。

ソフトウェアがコンピュータゲームなど、３次元グラフィックス処理を伴う場合、サブプロセッサ３０とグラフィックプロセッサ１００との協働によって生成されたフレームデータは、グラフィックメモリ１０に格納され、表示装置５００に表示される。表示装置５００において、あるフレームの表示終了から次のフレームの表示終了までにかかる時間が垂直同期信号の周期であるから、動きのある画像を滞りなく表示しソフトウェアを正常に動作させるためには、所望の解像度や動作速度などに応じて、ソフトウェアごとに垂直同期信号の周期内で確保しなければならない処理時間が決まってくる。したがって処理時間属性の必要値を垂直同期信号の周期を単位に設定することにより、ソフトウェアの動作保障のための設定が容易になる。

本実施の形態では、処理時間属性をソフトウェアごとに保持することによって、ユーザがロード要求を行ったソフトウェアの動作環境を前もって把握し、正常な動作を保障できる場合に限りロードを行う。これにより、ロードを行ったにも関わらずソフトウェアがユーザの期待通りの動作をしないなどの不具合を未然に防ぐことができる。また予約済みソフトウェアのタスク処理時間を最低限確保できるか確認してから新規ソフトウェアのロードを行うため、新規ソフトウェアのロードによってすでに起動しているソフトウェアの動作に支障をきたすことがなくなる。さらに必要な処理時間が比較的短く、時間的制限の軽微なソフトウェアに対して、グラフィック処理などを含みリアルタイム性を要求されるソフトウェアに選択的に多くのタイムスライスを確保することによって、有限なプロセッサ資源の効率的な使用が可能となり、ユーザのニーズへ対応する余地が広がる。

上述の形態では、垂直同期信号の周期をソフトウェアに共通の単位期間とし、その単位期間に対する処理時間の絶対値をもって処理時間属性の必要値としたが、単位期間は、垂直同期信号の周期の倍数などでもよい。すなわち処理時間属性の必要値は、ある単位期間におけるタスク処理に必要な時間であればよい。または、ある単位期間に対するタスク処理に必要な時間の割合でもよい。さらに単位期間は、ソフトウェアに共通でなくてもよい。例えば、基準となる単位期間の値および、その期間中に必要な処理時間、の２値を処理時間属性とし、ソフトウェアごとに設定してもよい。そのほか、ある時刻と、それまでに必要な処理時間の絶対値、の２値を処理時間属性としてもよい。これらの処理時間属性の形式を混在させる場合は、処理時間属性にさらに記述形式を識別する識別子を付加し、管理プロセッサ３２を制御するＯＳによって識別するようにする。そして判定部６６は、識別子に基づき各ソフトウェアに付加された処理時間属性の形式をスケジュールファイルの形式に即した値に変換してから、タスクに必要な処理時間とサブプロセッサ３０の空き時間とを比較するようにしてもよい。この場合、ソフトウェアの内容に適した形式で処理時間属性を表現できるため、正常な動作の保障を確実化できるとともに、ＯＳの種類やバージョンアップなどによってスケジュールファイルの形式が変化しても、ソフトウェアの属性ファイルを書き変えることなく本実施の形態を適用することができる。

実施の形態２
本実施の形態は、実施の形態１における図１で示した情報処理装置１０００および、図２で示した管理プロセッサ３２と同様の構成で実施することができる。ここでは主に、実施の形態１との相違点に着目し、説明する。

実施の形態１では処理時間属性として処理時間の必要値のみを設定した。これにより新規タスクを含む各タスクは、全サブプロセッサ３０を必要値に示された処理時間で占有した。すなわち、メインプロセッサ２００が同時に処理するのはひとつのタスクとなっていた。本実施の形態では処理時間属性として、処理時間の必要値に加えサブプロセッサの必要個数を設定し、同時に複数のタスクを処理するようなスケジューリングに対応させる。

図９は本実施の形態におけるスケジュールファイルに記述されるタスクの割り当て状況の例を模式的に示している。本実施の形態では処理時間属性としてサブプロセッサ３０の必要個数および、それらのサブプロセッサ３０によって処理した際に必要となる処理時間とを設定できることから、同時に複数のタスクを処理することが可能となる。図９の例では、３つのタスク、タスクＡ、タスクＢ、およびタスクＣがスケジューリングされているが、タスクＣのように長時間のシリアル処理が必要なタスクを処理する場合などに、効率の良い処理を行うことのできるサブプロセッサ３０の割り当てが可能であり、本実施の形態での処理時間属性の設定はこのようなスケジューリング手法に対応する。

図１０は、本実施の形態における属性ファイルのデータ構造の例を示している。本実施の形態の属性テーブル７１は、実施の形態１と同様、属性名称欄７１ａおよび必要値欄７１ｂを含む。本実施の形態では、必要値欄７１ｂにはサブプロセッサの必要個数および処理時間の必要値の２値が記載される。

次に本実施の形態において主に管理プロセッサ３２によって行われる処理について説明する。新規ソフトウェアのロード要求受け付けから、一般的な属性に係る処理は、実施の形態１における図５と同様の処理を行う。図１１は、一般的な属性について実行可能の判定がなされたら（Ｓ１２のＹ）、それに引き続き行われる、処理時間属性に係る処理手順を示している。

まず実施の形態１と同様、属性ファイル内の処理時間属性を検出し、必要値を読み込み（Ｓ３０）、スケジュールファイルに記載された予約済みタスクの割り当て状況からサブプロセッサ３０の空き時間を導出する（Ｓ３２）。そして処理時間の必要値とサブプロセッサ３０の空き時間との比較を行う（Ｓ３４）。但し、本実施の形態における「必要値」は上述の２値であり、「空き時間」は、上述のとおり必要個数分のサブプロセッサが同時期に有する空き時間である。

必要な処理時間がサブプロセッサ３０の空き時間を上回っていると判定された場合（
Ｓ３４のＮ）、本実施の形態では、スケジュールファイルに記載された予約済みタスクの割り当てスケジュールについて仮調整を行い（Ｓ３５）、再度処理時間の必要値とサブプロセッサ３０の空き時間との比較を行う（Ｓ３６）。ここで行われるスケジュールの仮調整は、実際のタスク処理とは独立に、計算のみで行う思考実験的な処理である。処理時間の必要値がサブプロセッサ３０の空き時間を超えないと判定された場合は（Ｓ３４のＹ、Ｓ３６のＹ）、実施の形態１の図７のごとく、起動処理部６８はロードの完了（Ｓ３８）およびスケジュールファイルの更新（Ｓ４０）を行う。このとき、スケジュールの仮調整を行ってロードが許可された場合は、その仮調整の内容も反映させる。スケジュールの仮調整を行っても十分な空き時間を確保できない場合は（Ｓ３６のＮ）、実施の形態１と同様に、新規ソフトウェアのロード不許可処理を行い（Ｓ３７）、シーケンスを終了する。

図９に示した割り当て状況を例に、図１１の手順を説明すると次のようになる。例えばユーザがロードを要求した新規ソフトウェアの処理時間属性として、サブプロセッサ３０の必要個数が３個、処理時間の必要値が単位期間の２０％に相当する値であった場合、タスクＢが終了した時点以降、３つのサブプロセッサ３０ａ、３０ｂおよび３０ｃに、単位期間に対する割合にして４０％の空き時間が確保できるため、Ｓ３４において空き時間は十分であると判定される。一方、サブプロセッサ３０の必要個数が１個で、処理時間の必要値が単位期間の９０％に相当する値である場合は、最も空き時間の長いサブプロセッサ３０ｃにおいても、その空き時間が単位期間の８０％であるため、Ｓ３４において処理時間の必要値が空き時間を上回ると判定される。そこでＳ３５においてタスクＣの処理を、サブプロセッサ３０ｃのタスクＡの処理後に行うようにスケジュールの仮調整を行う。するとサブプロセッサ３０ｄの空き時間が単位期間の１００％となるため、Ｓ３６において処理時間の必要値が空き時間を超えないと判定され、当該新規ソフトウェアのロードが許可される。

本実施の形態によれば、実施の形態１と同様、ロード要求がなされたソフトウェアの動作環境を把握し、正常な動作を保障できる場合に限りロードを行うため、新規ソフトウェアや予約済みソフトウェアの動作不具合の発生を防止できる。さらに、短期間のパラレル処理を必要とするタスク、長期間のシリアル処理を必要とするタスクなど、個々のタスクの処理態様を時間処理属性としてあらかじめ取得することにより、処理時間の割り当てのみならず、サブプロセッサ３０の割り当てに対して自由度を有するスケジューリングに対応させることができ、より柔軟なロード許可判定を行うことができる。これにより上述した効果を、より効率的な資源の使用とともに得ることができ、ユーザのニーズに対応する余地が広がる。

実施の形態３
本実施の形態は、実施の形態１における図１で示した情報処理装置１０００および、図２で示した管理プロセッサ３２と同様の構成で実施することができる。ここでは主に、実施の形態１および２との相違点に着目し、説明する。

実施の形態１および２では新規ソフトウェアのロード要求に対し、属性ファイル内の処理時間属性を取得した。本実施の形態ではさらにバス帯域属性を取得する。そして、予約済みタスクのバス帯域の予約状況を記載したバス帯域予約ファイルに基づき、新規ソフトウェアの実行可否判定を行う。

図１２は、本実施の形態における属性ファイルのデータ構造の例を示している。本実施の形態の属性テーブル７２は、属性名称欄７２ａ、必要値欄７２ｂおよび、識別子欄７２ｃを含む。ここでは、「処理時間」属性に対し、タスクの処理に必要なサブプロセッサ３０の個数および処理時間が、「バス帯域」属性に対し、タスク処理中のデータ転送に必要なバス帯域の割合が、必要値欄７２ｂに記述されている。必要なバス帯域の割合は、情報処理装置１０００に設けられたバス４０の帯域に対して必要とされる割合である。必要なバス帯域の割合に代わり、必要なバス帯域の絶対値や、必要なデータ転送速度で表してもよい。必要なデータ転送速度から、情報処理装置１０００が有するクロック周波数特性を用いて、必要なバス帯域を算出できる。

データを転送する区間によって専用のバスが設けられるなどバス帯域が異なったり、各タスクが必要とする転送速度が異なったりするため、バス帯域の必要値は複数設定できるようにする。特にメインメモリ５０とメインプロセッサ２００との間のデータ転送、グラフィックプロセッサ１００とメインプロセッサ２００との間の転送、およびメインプロセッサ２００と入出力プロセッサ６５０との間の転送は、タスクの処理速度に大きく影響するため、本実施の形態ではそれらの区間において必要なバス帯域の割合を、バス帯域の必要値とする。このため、各必要値に対応するバス４０の区間を識別するための識別子が識別子欄７２ｃに記載される。図１２の例では、「ｍｅｍ」はメインメモリ５０とメインプロセッサ２００との間、「ｇｒａ」はグラフィックプロセッサ１００とメインプロセッサ２００との間、「ｉｏ」はメインプロセッサ２００と入出力プロセッサ６５０との間のバス４０をそれぞれ表している。バス帯域の必要値も処理時間属性と同様、過負荷での検証実験などによって得られた値を設定する。

次に本実施の形態において主に管理プロセッサ３２によって行われる処理について説明する。新規ソフトウェアのロード要求受け付けから、処理時間属性に係る処理は、実施の形態１における図５、および実施の形態２における図１１と同様の処理を行う。図１３は、処理時間属性について実行可能の判定がなされたら（Ｓ３４のＹ、Ｓ３６のＹ）、それに引き続き行われる、バス帯域属性に係る処理手順を示している。

まず属性取得部６２は属性ファイル内のバス帯域属性を検出し、必要値および識別子を全て読み込む（Ｓ４２）。次いで状況取得部６４は、バス帯域予約ファイルをメインメモリ５０より取得し、同時に処理が行われる予約済みタスクが予約したバス帯域の合計から、新規タスクのために確保できるバス帯域の時間変化を識別子で識別されたバスの区間ごとに導出する（Ｓ４４）。バス帯域予約ファイルは、予約済みソフトウェアをロードした際に読み込んだ、バス帯域属性の必要値および識別子を記載したファイルである。一方、あらかじめ算出した確保できるバス帯域の時間変化を別のファイルとしてメインメモリ５０に格納しておき、ソフトウェアをロード、もしくはアンロードする都度、当該パラメータを計算し直してファイルを更新するようにしてもよい。この場合上述したＳ４４のステップは、当該ファイルを参照するのみでよい。

そして判定部６６は、新規ソフトウェアのバス帯域属性内の必要値をバスの区間ごとに、確保できるバス帯域と比較する（Ｓ４６）。予約済みタスクの処理スケジュールに応じて、確保できるバス帯域は時間依存の変数となるため、Ｓ４６の処理は実際には、新規タスクに必要な処理時間とバス帯域の双方に基づき比較を行う。新規タスクに必要なバス帯域が、バスの区間のいずれかにおいて、確保できるバス帯域を上回っていると判定された場合（Ｓ４６のＮ）、まずスケジュールファイルに記載された予約済みタスクの割り当てスケジュールについて、実施の形態２と同様の調整を行い（Ｓ４７）、再度バス帯域属性の必要値と確保できるバス帯域との比較を行う（Ｓ４８）。スケジュールを調整してもなお、十分なバス帯域を確保できない場合は（Ｓ４８のＮ）、新規タスクが必要とするバス帯域を確保できない旨の通知を表示装置５００に表示し、ロード処理を続行するかどうかをユーザへ確認する（Ｓ４９）。

ユーザがロードのキャンセルを選択した場合（Ｓ４９のＮ）、起動処理部６８が実施の形態１で述べたロード不許可処理を行い（Ｓ５０）、シーケンスを終了する。一方、新規タスクに必要なバス帯域が確保できるバス帯域をどの時間においても超えないようにスケジューリングできると判定された場合（Ｓ４６のＹ、Ｓ４８のＹ）または、必要なバス帯域が確保できるバス帯域を超えていてもユーザがロードの続行を希望した場合（Ｓ４９のＹ）、図７のごとく、起動処理部６８はロードの完了（Ｓ３８）およびスケジュールファイルの更新（Ｓ４０）を行う。このとき、スケジュールの仮調整を行ってロードが許可された場合は、その仮調整の内容も反映させる。Ｓ４０ではさらに、バス帯域予約ファイルに、ロードしたソフトウェアのタスクが使用できるバス帯域を書きこむ。ここで、必要なバス帯域が確保できるバス帯域を超えない場合は（Ｓ４６のＹ）、その必要なバス帯域が書きこまれ、必要なバス帯域が確保できるバス帯域を上回り（Ｓ４６のＮ）、ユーザの選択により（Ｓ４９のＹ）ロードされた新規ソフトウェアについては、Ｓ４４で取得した確保できるバス帯域を書き込み、予約する。確保できるバス帯域が時間によって変化する場合は、その最小値を使用できるバス帯域としてもよいし、時間変化をそのまま反映した形で予約してもよい。これにより、必要なバス帯域が確保できた場合は望ましいバス帯域を使用し、必要なバス帯域が確保できなかった場合は最大限使用できるバス帯域を利用して、新規タスクの処理がなされる。

ここで再度、図９に示した割り当て状況を例にとり、図１３の手順を説明すると次のようになる。ある転送区間において、図９に示された３つの予約済みタスクＡ、タスクＢおよびタスクＣは、それぞれ６０％、４０％および４０％のバス帯域を予約しているとする。さらに、ユーザがロードを要求した新規ソフトウェアの処理時間属性は、サブプロセッサ３０の必要個数が３個、処理時間の必要値が単位期間の２０％、バス帯域属性は必要値が８０％であったとする。この場合、図１１の処理時間属性に係る処理では、実施の形態２で説明したように、３つのサブプロセッサ３０ａ、３０ｂおよび３０ｃにおいて、タスクＢが終了した時点以降、十分な空き時間があるため、例えばタスクＢが終了した直後の３つのサブプロセッサ３０ａ、３０ｂおよび３０ｃに新規タスクを割り当てることにより新規ソフトウェアは実行可能との判定がなされる。しかしながら、このような割り当てを行った場合、新規タスクの開始時にはサブプロセッサ３０ｄによってバス帯域の必要値が４０％であるタスクＣの処理がなされているため、確保できるバス帯域は６０％であり、バス帯域属性に係る判定、すなわち図１３のＳ４６で、必要なバス帯域８０％が確保できるバス帯域を超えていると判定される。

そこでＳ４７において、タスクＣの処理が終了した後の４つのサブプロセッサ３０ａ、３０ｂ、３０ｃおよび３０ｄのうちのいずれか３つに新規タスクを割り当てるようにスケジュールの仮調整を行う。タスクＣの処理の終了後は予約済みタスクの処理は行われないため、確保できるバス帯域は１００％となり、Ｓ４８において必要なバス帯域が確保できるバス帯域を超えないと判定され、当該新規ソフトウェアのロードが許可される。この例では、新規タスクに対してのみスケジュールの仮調整を行ったが、実施の形態２と同様、新規タスクが処理時間とバス帯域の双方に対して必要値を満足するように、予約済みタスクのスケジュール仮調整を同時に行ってもよい。あるいは予約済みタスクのみスケジュール仮調整を行ってもよい。

上述の例におけるタスクＡとタスクＣのように、メインプロセッサ２００において同時に処理されるタスクのバス帯域の必要値の合計が１００％である場合には、それぞれが使用するバス帯域が予約した値を超えないようにハードウェアによって制御を行う。これにより、本実施の形態によって一旦ロードの許可がなされ、バス帯域の必要値を予約できたソフトウェアは、他にどのようなソフトウェアが実行されようとも、その必要値を最低限確保できることになる。一方タスクＢとタスクＣのように、バス帯域の必要値の合計が１００％未満であった場合は、ハードウェア制御により余ったバス帯域を適宜両タスクに割り振ることにより、より効率のよい資源の使用が可能となる。

例えばコンピュータゲームなど、３次元グラフィックス処理を伴うソフトウェアを実行する場合、図１に示した情報処理装置１０００において、メインプロセッサ２００が処理するタスクに含まれる画像処理はグラフィックプロセッサ１００が行い、画像処理に係る情報はメインメモリ５０に格納される。したがってフレームデータを生成し、滞りなく表示装置５００に表示することによりゲームのリアルタイム性を確保するためには、各プロセッサの処理速度とともにメインプロセッサ２００とメインメモリ５０間や、メインプロセッサ２００とグラフィックプロセッサ１００間の画像処理に係るデータの転送速度が重要な要素となる。すなわちフレームデータの生成に際し、それに必要なデータの転送が間に合わなければ、結果的に表示装置５００に表示されるフレームレートに影響を与えることになる。したがって本実施の形態では、望ましい解像度や動作速度で動画を表現するために最低限必要とされるバス帯域をバス帯域属性としてソフトウェアごとに保持する。これにより、実施の形態１および２と同様、新規ソフトウェアの動作環境をロード前に把握することができ、ロードを行ったにも関わらずソフトウェアがユーザの期待通りの動作をしないなどの不具合を未然に防ぐことができる。

一方、本実施の形態では、新規タスクが必要とするバス帯域が確保できるバス帯域を超えていてもロードする可能性が残されている。これはもし望ましいバス帯域が得られなくても、遅い速度での進行をユーザが許容する場合が考えられるためである。したがってＳ４９のユーザ確認処理では、動作速度が低下する可能性がある旨の警告を表示するようにしてもよい。

本実施の形態によれば、上述のとおり新規ソフトウェアの動作にユーザが期待しない不具合が生じるのをロード前に防止することができるとともに、すでに実行されているソフトウェアのタスクに必要なバス帯域も必ず確保されるため、新規ソフトウェアがロードされることによってそれらのソフトウェアの動作に支障をきたすことがなくなる。さらにデータ転送量が小さい、または、時間的制限の軽微なタスクに対して、グラフィック処理などを含みリアルタイム性を要求されるタスクに選択的に多くのバス帯域を確保することによって、有限なプロセッサ資源の効率的な使用が可能となり、ユーザのニーズに適合した処理を行うことができる。本実施の形態では実施の形態１および２と同様に、処理時間属性の確認も行われるため、処理時間およびバス帯域の両側面からの確認およびタスクの選択ができ、また個々のタスクの処理態様に応じたスケジューリングに対応するため、より効果的な資源使用、および正常な動作保障を行うことができる。

実施の形態４
本実施の形態は、実施の形態１における図１で示した情報処理装置１０００および、図２で示した管理プロセッサ３２と同様の構成で実施することができる。ここでは主に、実施の形態１および２との相違点に着目し、説明する。

実施の形態１および２では新規ソフトウェアのロード要求に対し、属性ファイル内の処理時間属性を取得した。本実施の形態ではさらに優先度属性を取得する。そして、予約済みタスクの優先度を記載した優先度ファイルに基づき、新規ソフトウェアの実行可否判定を行うが、この場合はさらに、予約済みソフトウェアをも実行可否判定の対象とする。

図１４は、本実施の形態における属性ファイルのデータ構造の例を示している。本実施の形態の属性テーブル７４は、実施の形態１と同様、属性名称欄７４ａおよび必要値欄７４ｂを含む。ここでは、「処理時間」属性に対し、タスクの処理に必要なサブプロセッサ３０の個数および処理時間が、「優先度」属性に対し、タスクの優先度が、それぞれ必要値欄７４ｂに記載される。

優先度は、新規タスクと予約済みタスク間、または予約済みタスクどうしで比較される相対値であり、例えば１から５までの５段階の自然数によって表現する。図１４の例では５段階のうち「４」の優先度を有している。優先度は、ソフトウェアの出荷時に内容に応じて設定される。

次に本実施の形態において主に管理プロセッサ３２によって行われる処理について説明する。新規ソフトウェアのロード要求受け付けから、一般的な属性に係る処理は、実施の形態１における図５と同様の処理を行う。図１５は、一般的な属性について実行可能の判定がなされたら（Ｓ１２のＹ）、それに引き続き行われる、処理時間属性および優先度属性に係る処理手順を示している。

まず実施の形態２と同様、属性ファイル内の処理時間属性を検出し、必要値を読み込み（Ｓ３０）、スケジュールファイルに記載された予約済みタスクの割り当て状況からサブプロセッサ３０の空き時間を導出する（Ｓ３２）。そして処理時間の必要値とサブプロセッサ３０の空き時間との比較を行う（Ｓ３４）。当初の予約済みタスクのスケジュールでは十分な空き時間が確保できない場合は、実施の形態２と同様、スケジュールの仮調整を行ったうえで再度比較を行うが、図の簡単のため、図１５においてはそれらの処理もＳ３４に含めるものとする。

本実施の形態では、必要な処理時間がサブプロセッサ３０の空き時間を上回っていると判定された場合（Ｓ３４のＮ）、属性取得部６２が、属性ファイル内の優先度属性を検出し読み込む（Ｓ５６）。次いで状況取得部６４は優先度ファイルをメインメモリ５０より取得し、予約済みタスクの優先度を全て特定する（Ｓ５８）。優先度ファイルは、予約済みソフトウェアをロードした際に読み込んだ優先度データを蓄積したファイルである。

そして判定部６６は、新規タスクの優先度と、予約済みタスクの優先度を比較する（Ｓ６０）。新規タスクの優先度より低い優先度の予約済みタスク（以後、低優先度タスクと呼ぶ）が存在する場合（Ｓ６０のＹ）、そのうちのひとつを例えばタスクの優先度に基づいて抽出し、抽出された低優先度タスクの処理予約を仮に取り消した場合（Ｓ６４）の、サブプロセッサ３０の仮の空き時間を算出する（Ｓ３２）。そして判定部６６が新規タスクに必要な処理時間と仮の空き時間とを比較する（Ｓ３４）。この場合も仮の空き時間が足りない場合は、残りの予約済みタスクに対してスケジュールの仮調整を行ったうえで再度比較をする処理を含めてよい。予約の仮取り消しなどは、実際のタスク処理とは独立に、計算のみで行う思考実験的な処理である。

新規タスクに必要な処理時間が空き時間を超えない場合は（Ｓ３４のＹ）、抽出した低優先度タスクを停止する旨の警告を表示装置５００に表示のうえ（Ｓ６８）、当該タスクを停止し（Ｓ７０）、スケジュールファイルより予約を取り消す（Ｓ７２）。そして図７のごとく、ロードの完了（Ｓ３８）およびスケジュールファイルの更新（Ｓ４０）を行う。Ｓ４０ではさらに、ロードしたソフトウェアのタスクの優先度を優先度ファイルに書き込む。Ｓ６８の、低優先度タスクの停止に関する警告では、低優先度タスクの実行停止の可否をユーザに判断させるようにしてもよい。この場合は、ユーザが当該タスクの実行停止を拒否したら、新規ソフトウェアのロード不許可処理を行い、シーケンスを終了する。一方、ユーザが実行停止を了承したら、上述のように新規ソフトウェアのロード処理を行う。

必要な処理時間が仮の空き時間を上回る場合は（Ｓ３４のＮ）、優先度ファイルにさらに低優先度タスクがあれば（Ｓ６０のＹ）、そのタスクを仮に取り消した場合（Ｓ６４）の仮の空き時間と新規タスクに必要な処理時間とを比較する（Ｓ３２、Ｓ３４）。以上の処理を、新規タスクに必要な処理時間が仮の空き時間を超えなくなる（Ｓ３４のＹ）まで繰り返すが、その前に取り消すことのできる低優先度タスクが存在しなくなったら（Ｓ６０のＮ）、新規ソフトウェアのロード不許可処理を行う（Ｓ６２）。これらの処理により、先に実行されていても優先度の低いタスクを停止させ、その代わりに新規タスクを起動させることができる。

本実施の形態によれば、実施の形態１および２と同様、新規ソフトウェアの動作、および予約済みソフトウェアの動作にユーザが期待しない不具合が生じるのをロード前に防止することができ、さらにプロセッサ資源を効率的に使用することができる。さらに本実施の形態では、優先度属性を導入することによって、新規タスクに必要な処理時間がサブプロセッサ３０の空き時間を上回った場合でも、予約済みタスクの停止を視野に入れてロード可否判断がなされるため、ソフトウェアの内容などに応じた柔軟な対応を行うことができる。

実施の形態５
本実施の形態は、実施の形態１における図１で示した情報処理装置１０００および、図２で示した管理プロセッサ３２と同様の構成で実施することができる。ここでは主に、実施の形態１〜４との相違点に着目し、説明する。

実施の形態４では、新規タスクが必要とする処理時間属性とサブプロセッサ３０の空き時間との比較に際し、優先度属性を導入した。本実施の形態ではさらに、実施の形態３で述べた新規タスクが必要とするバス帯域と、バス帯域予約ファイルに基づく確保できるバス帯域との比較においても同じ優先度属性を参照する。さらに本実施の形態では、バス帯域属性を、最適バス帯域と最低必要バス帯域との２段階に分けて表現する。そして新規タスクおよび予約済みタスクの優先度に基づき各タスクの使用バス帯域を調整しながら、実行可否判定を行う。

図１６は、本実施の形態における属性ファイルのデータ構造の例を示している。本実施の形態の属性テーブル７６は、属性名称欄７６ａ、第一必要値欄７６ｂ、第二必要値欄７６ｃおよび、識別子欄７６ｄを含む。「処理時間」属性に対し、タスクの処理に必要なサブプロセッサ３０の個数および処理時間が、「優先度」属性に対し、タスクの優先度が、それぞれ第一必要値欄７６ｂに記載される。「バス帯域」属性は、タスクの処理に最適なバス帯域の割合が第一必要値欄７６ｂに、動作に不具合が生じない範囲で最低限必要なバス帯域の割合が第二必要値欄７６ｃに、バスの区間を識別するための識別子が識別子欄７６ｄに記載される。各タスクは、他のタスクとの優先度の比較によって、第一必要値欄７６ｂ、および第二必要値欄７６ｃに記載された数値に基づき、その使用バス帯域が決定される。決定手順について以下に述べる。

図１７は本実施の形態において参照されるバス帯域予約ファイルに格納されたバス帯域予約テーブルのデータ構造の例を示している。バス帯域予約テーブル７８は、ソフトウェア名欄７８ａ、タスクナンバー欄７８ｂ、最適値欄７８ｃ、最低値欄７８ｄおよび使用値欄７８ｅを含む。各ソフトウェアに対し、スケジューリングされたタスクは番号付けされ、その番号がタスクナンバー欄７８ｂに示される。さらにそれぞれのソフトウェアのバス帯域属性より読みだされた、第一必要値および第二必要値が、最適バス帯域および最低バス帯域としてそれぞれ最適値欄７８ｃおよび最低値欄７８ｄに示される。さらに現在予約されている、すなわち各タスクが使用できるバス帯域の割合が使用値欄７８ｅに示される。この使用バス帯域は、後述のバス帯域属性に係る処理において自動的に決定される。バス帯域の使用値は最適値が上限、最低値が下限となる。またバス帯域使用値は実施の形態３で説明したとおり、ハードウェアによって最低限保障される。

本実施の形態において、主に管理プロセッサ３２によって行われる処理について説明する。新規ソフトウェアのロード要求受け付けから、優先度を考慮した処理時間属性に係る処理は、実施の形態１における図５および、実施の形態４における図１５と同様の処理を行う。図１８は、処理時間属性について実行可能の判定がなされたら（Ｓ３４のＹ、Ｓ６６〜Ｓ７２）、それに引き続き行われる、優先度を考慮したバス帯域属性に係る処理手順を示している。

まず属性取得部６２は、新規ソフトウェアの属性ファイル内のバス帯域属性を検出し、第一必要値、第二必要値、および識別子を読み込む（Ｓ７４）。次に状況取得部６４は、バス帯域予約ファイルに基づき確保できるバス帯域の時間変化をバスの区間ごとに導出する（Ｓ７６）。

次いで判定部６６は、新規ソフトウェアのバス帯域属性のうち第一必要値を取得し、バスの区間ごとに、確保できるバス帯域との比較を行う（Ｓ７８）。ここでの比較も実施の形態３と同様に、新規タスクの必要処理時間を考慮する。また当初の予約済みタスクの割り当てスケジュールでは十分なバス帯域が確保できない場合は、実施の形態３と同様、スケジュールの仮調整を行ったうえで再度比較を行うが、図の簡単のため、図１８においてはそれらの処理もＳ７８に含めるものとする。新規タスクの最適バス帯域が、バスの区間において、確保できるバス帯域をどの時間においても超えないようにスケジューリングできると判定された場合は（Ｓ７８のＹ、Ｓ８８のＮ）、図７のごとく、ロードの完了（Ｓ３８）およびスケジュールファイルおよびバス帯域予約ファイルを更新する（Ｓ４０）。このときバス帯域予約テーブル７８の新規ソフトウェアの使用値欄７８ｅには、最適バス帯域が記載される。

一方、最適バス帯域が確保できるバス帯域を上回っていると判定された場合（Ｓ７８のＮ）、判定部６６は、処理時間属性に係る処理時に読み込まれた新規タスクの優先度（図１５のＳ５６）と、予約済みタスクの優先度（同図のＳ５８）とを比較する（Ｓ８０）。低優先度タスクが存在しない場合（Ｓ８０のＮ）、起動処理部６８は新規ソフトウェアのロード不許可処理を行う（Ｓ８２）。低優先度タスクが存在する場合（Ｓ８０のＹ）、状況取得部６４はバス帯域予約ファイルを参照し、低優先度タスクのうち、最低バス帯域より大きい値が使用バス帯域となっているものを抽出する（Ｓ８４）。該当する低優先度タスクがあったら（Ｓ８４のＹ）、そのうちのひとつの使用値を仮に削減した場合の、仮に確保できるバス帯域を算出する（Ｓ８６、Ｓ７６）。そして判定部６６が新規タスクの最適バス帯域と仮に確保できるバス帯域とを比較する（Ｓ７８）。低優先度タスクの使用バス帯域の削減は、最低バス帯域を限度とする。削減は判定部６６による判定結果を見ながら徐々に行ってもよい。さらに、複数の低優先度タスクから均等に、徐々に削減していってもよい。

新規タスクの最適バス帯域が確保できたら（Ｓ７８のＹ）、起動処理部６８は、バス帯域の削減対象となった低優先度タスクの処理動作が遅くなる可能性についての警告を表示装置５００に表示のうえ（Ｓ８８のＹ、Ｓ９０）、当該タスクの使用バス帯域を削減するようバス帯域予約テーブル７８の該当ソフトウェアの使用値欄７８ｅを変更する（Ｓ９２）。そして、図７のごとく、起動処理部６８が新規ソフトウェアのロードの完了（Ｓ３８）およびスケジュールファイル、バス帯域予約ファイル、および優先度ファイルの更新処理を行う。Ｓ９０のステップではユーザに対し、低優先度タスクの動作が遅くなってもよいか問い合わせるようにしてもよい。この場合は、ユーザが当該タスクの動作速度低減を拒否したら、Ｓ８２と同様に新規ソフトウェアのロードを行わない。一方、ユーザが動作速度低減を了承したら、上述のロード完了処理を行う。

新規タスクの最適バス帯域が仮に確保できるバス帯域を上回る場合（Ｓ７８のＮ）、さらに使用バス帯域が最低バス帯域より大きい低優先度タスクがあれば（Ｓ８０のＹ、Ｓ８４のＹ）、その使用バス帯域を削減した場合の仮に確保できるバス帯域と新規タスクの最適バス帯域とを比較する（Ｓ８６、Ｓ７６、Ｓ７８）。以上の処理を、新規タスクの最適バス帯域が仮に確保できるバス帯域を超えなくなる（Ｓ７８のＹ）まで繰り返すが、その前に低優先度タスク全ての使用バス帯域を最低バス帯域に設定してもなお、新規ソフトウェアの最適バス帯域分を確保できない場合は（Ｓ８４のＮ）、新規タスクの使用バス帯域を仮に削減し（Ｓ９４、Ｓ９６）、仮に確保できたバス帯域を超えないか判定する（Ｓ７８）。新規タスクの使用バス帯域の削減も、バス帯域属性の第二必要値を限度とする。そして、仮に確保できるバス帯域を超えなければ（Ｓ７８のＹ）、起動処理部６８は、バス帯域の削減対象となった低優先度タスクの動作が遅くなる可能性、および、新規タスクの動作が遅くなる可能性についての警告を表示装置５００に表示のうえ（Ｓ８８のＹ、Ｓ９０）、低優先度タスクの使用バス帯域を削減するようバス帯域予約テーブル７８の該当ソフトウェアの使用値欄７８ｅを変更する（Ｓ９２）。そして、図７のごとく、新規ソフトウェアのロードの完了（Ｓ３８）およびスケジュールファイル、バス帯域予約ファイル、および優先度ファイルの更新処理（Ｓ４０）を行う。このとき、新規ソフトウェアのタスクの使用バス帯域はバス帯域属性の第一必要値から削減した値を記載する。

新規タスクの使用バス帯域を第二必要値まで削減しても仮に確保できたバス帯域を超える場合は（Ｓ７８のＮ）、起動処理部６８は、新規タスクの最低バス帯域を確保できるまで低優先度タスクを優先度などに基づき抽出し、実施の形態４の図１５におけるＳ６８、Ｓ７０、Ｓ７２で行ったのと同様の低優先度タスクの停止処理を行う（Ｓ９８）。そして上述の新規ソフトウェアのロード処理（図７のＳ３８、Ｓ４０）を行う。

以上の処理により、新規タスク、予約済みタスクの双方の使用バス帯域を許容範囲内で調整しながら、可能な限り全てのタスクを実行することができる。さらに、使用バス帯域の削減や低優先度タスクの停止を行う前にユーザへ確認する態様とすれば、動作が遅くなる可能性があっても全てのタスクを実行する、動作を遅くせず優先度の低いタスクを停止する、など多様な対策の中からのユーザによる選択が可能となる。

本実施の形態では、実施の形態１〜４と同様、新規ソフトウェアの動作、および予約済みソフトウェアにユーザが期待しない不具合が生じるのをロード前に防止することができ、さらにプロセッサ資源を効率的に使用することができる。また実施の形態４と同様、優先度属性を導入することによって処理時間に対してより柔軟な運用形態となる。さらに、バス帯域に対する判定にも優先度属性を導入することにより、優先度に応じてロードの可否判断がなされるとともに、バス帯域の調整を自動的に行うことができ、ロードの可否のみならず使用バス帯域についても柔軟な運用形態となるほか、より効率的な資源の使用を行うことができる。

なお、本実施の形態ではバス帯域属性として第一必要値と第二必要値の２段階で表現したが、必要値をひとつ設定し、それが厳守値であるか望ましい値であるかを識別するようにしてもよい。この場合、設定されたバス帯域が厳守値であるタスクの使用バス帯域は優先度に関わらず削減対象からはずす。望ましい値であるタスクの使用バス帯域は、例えばある共通の最低必要バス帯域をあらかじめ設定しておき、その値まで削減させてよいとする。この場合も、上述の場合と同様の効果を得ることができる。

実施の形態６
本実施の形態は、実施の形態１における図１で示した情報処理装置１０００および、図２で示した管理プロセッサ３２と同様の構成で実施することができる。また、管理プロセッサ３２で行われる処理手順は実施の形態１〜５のいずれかと同様に行われる。ここでは主に、実施の形態１との相違点に着目し、説明する。

図１９は本実施の形態における記憶装置６００の構成を模式的に示している。実施の形態１では、処理時間属性やバス帯域属性を示すファイルが、ソフトウェアのプログラムファイルと同一の、ＣＤ−ＲＯＭなどの記憶装置に格納されているとしたが、本実施の形態では属性ファイルはプログラムファイルとは異なる記憶装置６００に格納される。そして属性取得部６２は、新規ソフトウェアのロード処理とは別に、属性ファイルの格納された記憶装置６００から属性ファイルのみをまずメインメモリ５０にロードし、属性ファイルに含まれる処理時間属性、バス帯域属性、優先度属性のデータに基づき、ロード可否の判定を行う。

本実施の形態によれば、管理プロセッサ３２の処理動作などを制御するＯＳのバージョンが更新されたり、プロセッサの演算速度やバス帯域が大きい情報処理装置１０００の機種が新たに製品化されたりした場合でも、それらの変化に対応した属性ファイルを記憶したＣＤ−ＲＯＭなどの記憶装置６００のみを新たに読み込ませれば、プログラムファイルを格納した記憶装置６００はそのまま利用することができる。これによりユーザは、実施の形態１〜５で説明したのと同様の効果と、最新環境がもたらす処理速度に係る効果との相乗効果を容易に享受することができる。また、属性ファイルの記憶装置６００を情報処理装置１０００に接続したハードディスクとすれば、例えば優先度属性などをユーザが自分の好みに応じて書き変えることも可能となる。これにより、よりユーザのニーズに即したロード処理を行うことができる。

実施の形態７
本実施の形態は、実施の形態１における図２で示した管理プロセッサ３２と同様の構成で実施することができるが、図１で示した情報処理装置１０００は図２０の全体構成で示すようにネットワークを介してサーバ７００に接続されている。管理プロセッサ３２で行われる処理手順は実施の形態１〜５のいずれかと同様に行われる。ここでは主に、実施の形態１および６との相違点に着目し、説明する。

図２０は本実施の形態におけるシステムの全体構成を示している。実施の形態１〜６では、処理時間属性やバス帯域属性を示すファイルが、ＣＤ−ＲＯＭなど情報処理装置１０００に直接接続された記憶装置６００に格納されているとしたが、本実施の形態ではサーバ７００において管理される。一方、ソフトウェアには、対応する属性ファイルの名称やＯＳのバージョン情報など、当該ソフトウェアに対応した属性ファイルをサーバより検出するための識別子が付加される。

そして属性取得部６２は、処理時間属性やバス帯域属性を取得する際、サーバ７００に問い合わせを行う。サーバ７００は情報処理装置１０００からの問い合わせに従い属性ファイルを検出し、情報処理装置１０００に対しダウンロードの準備ができた旨の通知を行う。属性取得部６２は当該通知を受けて属性ファイルのダウンロードを行うことにより、メインメモリ５０に格納する。その後は実施の形態１〜５と同様に、当該属性ファイルに含まれる処理時間属性、バス帯域属性、優先度属性のデータに基づき、ロード可否の判定を行う。

本実施の形態によれば、属性ファイルの管理は常にサーバ７００が行っているため、ソフトウェアメーカなどによる属性データの検証実験により属性データが改善された場合や、情報処理装置１０００で実行されるＯＳのバージョンが更新されたり、プロセッサの演算速度やバス帯域が大きい情報処理装置１０００の機種が新たに製品化されたりした場合でも、ソフトウェアに対応する範囲内で最新の属性データによる運用を自動的に行うことができる。これによりユーザは、実施の形態１〜５で説明したのと同様の効果と、最新環境がもたらす処理速度に係る効果との相乗効果を容易に享受することができる。

上述の構成では、識別子およびプログラムファイルは情報処理装置１０００に接続された記憶装置６００に格納されていたが、これらもサーバ７００に格納してよい。この場合、ユーザが表示装置５００上でソフトウェア名の選択などを行うと、対応する属性ファイルのダウンロードが先に行われる。これにより新規ソフトウェアのロード可否判定を行い、ロード可能と判定された場合に、情報処理装置１０００はその旨の信号をサーバ７００へ送信し、ソフトウェアのプログラムファイルのダウンロードを行う。このような構成により、新規ソフトウェアに係る記憶装置６００をユーザが全く保持せずとも、本実施の形態の実施が可能となり、上述と同様の効果を得ることができる。

実施の形態８
本実施の形態は、実施の形態１における図２で示した管理プロセッサ３２と同様の構成で実施することができるが、図１で示した情報処理装置１０００は実施の形態７と同様にネットワークを介してサーバ７００に接続されている。管理プロセッサ３２で行われる処理手順は実施の形態１〜５のいずれかと同様に行われる。ここでは主に、実施の形態７との相違点に着目し、説明する。

図２１は本実施の形態におけるシステムの全体構成を示している。実施の形態７では、処理時間属性やバス帯域属性を示す属性ファイルをサーバ７００で一元的に管理していたが、本実施の形態では、ソフトウェアのプログラムファイルが格納されているのと同一の記憶装置６００にも格納される。すなわち、ソフトウェアの出荷時にはその時点で最新の属性ファイルをプログラムファイルに付加しておく。その後、ソフトウェアメーカなどによる属性データの検証実験により属性データが改善された場合や、情報処理装置１０００で実行されるＯＳのバージョンが更新された場合などに、サーバ７００より属性ファイルを取得する。そのため、ソフトウェアには、付加された属性ファイルのバージョン情報や、その時点でのＯＳのバージョン情報などの識別子が付加される。

そして属性取得部６２は、処理時間属性やバス帯域属性を取得する際、まずサーバ７００に問い合わせを行い、属性ファイルのバージョンが更新されているかどうかを確認し、更新されていれば最新の属性ファイルをサーバ７００よりダウンロードする。さらに情報処理装置１０００で実行されているＯＳのバージョンが更新されている場合も、サーバ７００に問い合わせを行い、更新後のＯＳのバージョンに対応した属性ファイルをダウンロードする。ダウンロードの手順は実施の形態７と同様である。その後は実施の形態１から５と同様に、当該属性ファイルに含まれる処理時間属性、バス帯域属性、優先度属性のデータに基づき、ロード可否の判定を行う。

本実施の形態によれば、出荷時点で最新の属性データはソフトウェアが格納されているのと同一の記憶装置６００に格納されているため、情報処理装置１０００が例えネットワークと接続していない状態であったとしても運用が可能である。さらに実施の形態７と同様、属性データの改善、ＯＳのバージョンの更新、情報処理装置１０００の機種変更などの変化に適宜対応した最新の環境での運用が可能となり、実施の形態１〜５で説明したのと同様の効果と、最新環境がもたらす処理速度に係る効果との相乗効果を容易に享受することができる。

以上、本発明を実施の形態をもとに説明した。上記実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

実施の形態３および５では、バス帯域属性に係る処理を処理時間属性に係る処理の後に行ったが、処理時間属性に係る処理の前、あるいはバス帯域属性のみを参照する処理を行ってもよい。この場合も、本実施の形態と同様の効果を得ることができる。

また、各属性は別の属性ファイルに記述されてもよく、格納する記憶装置が異なっていてもよい。例えばユーザによる設定が容易な優先度属性のみを記載したファイルを初回ロード時にハードディスクなどに格納して更新、参照を行い、そのほかの属性はソフトウェアのプログラムファイルとともにＣＤ−ＲＯＭに格納したファイル、またはサーバ７００に格納されたファイルを参照してもよい。これにより、属性そのものの性質に応じた臨機応変な運用形態で、本実施の形態で述べた効果を得ることができる。

実施の形態１における情報処理装置の構成を示すブロック図である。 実施の形態１における管理プロセッサの構成を示すブロック図である。 実施の形態１における記憶装置の構成を模式的に示した図である。 実施の形態１における属性ファイルのデータ構造の例を示した図である。 実施の形態１において行われるソフトウェアのロード処理手順を示すフローチャートである。 実施の形態１において行われるソフトウェアのロード処理手順を示すフローチャートである。 実施の形態１において行われるソフトウェアのロード処理手順を示すフローチャートである。 実施の形態１においてスケジュールファイルに記述されるタスクの割り当て状況の例を模式的に示した図である。 実施の形態２においてスケジュールファイルに記述されるタスクの割り当て状況の例を模式的に示した図である。 実施の形態２における属性ファイルのデータ構造の例を示した図である。 実施の形態２において行われるソフトウェアのロード処理手順を示すフローチャートである。 実施の形態３における属性ファイルのデータ構造の例を示した図である。 実施の形態３において行われるソフトウェアのロード処理手順を示すフローチャートである。 実施の形態４における属性ファイルのデータ構造の例を示した図である。 実施の形態４において行われるソフトウェアのロード処理手順を示すフローチャートである。 実施の形態５における属性ファイルのデータ構造の例を示した図である。 実施の形態５におけるバス帯域予約ファイルのデータ構造の例を示した図である。 実施の形態５において行われるソフトウェアのロード処理手順を示すフローチャートである。 実施の形態６における記憶装置の構成を模式的に示した図である。 実施の形態７におけるシステムの全体構成を示した図である。 実施の形態８におけるシステムの全体構成を示した図である。

符号の説明

３０ サブプロセッサ、 ３２ 管理プロセッサ、 ４０ バス、 ５０ メインメモリ、 ６０ ロード要求受付部、 ６２ 属性取得部、 ６４ 状況取得部、 ６６ 判定部、 ６８ 起動処理部、 １００ グラフィックプロセッサ、 ２００ メインプロセッサ、 ６００ 記憶装置、 ６５０ 入出力プロセッサ、 ７００ サーバ、 １０００ 情報処理装置。

Claims (18)

1. 複数のプロセッサを備えた情報処理装置が実行する情報処理方法であって、
   新規タスクの実行要求を受け付けるステップと、
   前記新規タスクを処理するための所要プロセッサ数と所要処理時間を特定するステップと、
   プロセッサごとに予約済みタスクの処理順を表すスケジュールファイルをメモリから読み出し、前記新規タスクの所要プロセッサ数分のプロセッサにおける所要処理時間分の空き時間の有無を確認して新規タスクの実行可否を判定するステップと、
   前記新規タスクが実行可能と判定された場合、前記新規タスクを前記スケジュールファイルに予約するステップと、
   前記スケジュールファイルに基づき前記実行可能と判定された新規タスクを含むタスクの処理を行うステップと、
   を含み、
   前記実行可否を判定するステップは、予約済みタスクを処理するプロセッサ、および各プロセッサにおける処理順の少なくともいずれかを仮に変更して前記空き時間が生成できるか否かをさらに確認し、
   前記空き時間が生成できた場合、前記予約するステップは、仮に変更したスケジュールで前記スケジュールファイルを更新したうえで前記新規タスクを予約することを特徴とする情報処理方法。
2. 前記特定するステップは、前記新規タスクの処理における所要バス帯域をさらに特定し、
   前記実行可否を判定するステップは、前記所要プロセッサ数分のプロセッサにおいて前記所要処理時間分の空き時間がある場合、当該空き時間における、前記新規タスクおよび同時に処理される予約済みタスクの総所要バス帯域が、実装バス帯域を超えるか否かを確認して実行可否を判定することを特徴とする請求項１に記載の情報処理方法。
3. 前記実行可否を判定するステップは、前記新規タスクの優先度情報を取得するステップを含み、取得した優先度情報に基づいて前記実行可否を判定することを特徴とする請求項１に記載の情報処理方法。
4. 前記実行可否を判定するステップは、
   前記総所要バス帯域が実装バス帯域を上回っていた際、前記新規タスクの優先度情報と前記予約済みタスクの優先度情報を参照するステップをさらに含み、
   参照した前記優先度情報に基づいて前記新規タスクに加え前記予約済みタスクの実行可否を判定することを特徴とする請求項２に記載の情報処理方法。
5. 前記総所要バス帯域が実装バス帯域を上回っていた際、前記実行可否を判定するステップは、予約済みタスクを処理するプロセッサ、および各プロセッサにおける処理順の少なくともいずれかを仮に変更して前記総所要バス帯域が実装バス帯域を下回るか否かをさらに確認することを特徴とする請求項２に記載の情報処理方法。
6. 前記実行可否を判定するステップにおいて前記新規タスクが実行不可と判定された場合、前記新規タスクの実行要求を起こしたタスクに対して、その判定結果を通知するステップをさらに含むことを特徴とする請求項１から４のいずれかに記載の情報処理方法。
7. 前記実行可否を判定するステップにおいて前記新規タスクおよび前記予約済みタスクの一方が実行不可と判定された場合、前記装置を制御するシステム制御部に対して、その判定結果を通知するステップをさらに含むことを特徴とする請求項４に記載の情報処理方法。
8. 前記システム制御部に通知された前記判定結果に基づき、ユーザが認識可能な表現にて前記新規タスクおよび前記予約済みタスクの一方が実行不可と判定された旨の通知をユーザに対し行うステップをさらに含むことを特徴とする請求項７に記載の情報処理方法。
9. 通知を受けたユーザからの、実行不可と判定されたタスクの実行不履行の許可に係る情報の入力を受け付けるステップをさらに含み、前記許可に係る情報に基づき、前記新規タスクおよび前記予約済みタスクの実行可否を再判定することを特徴とする請求項８に記載の情報処理方法。
10. 前記特定するステップは、新規タスクを処理するための前記所要プロセッサ数、所要処理時間、および所要バス帯域の少なくともいずれかの情報を、新規タスクを実行するためのソフトウェアプログラムとは別に、ネットワークを介して接続したサーバから取得することを特徴とする請求項１に記載の情報処理方法。
11. 主に装置全体を統括的に制御する第一のプロセッサと、主に演算処理を行う第二のプロセッサと、処理するタスクに関する情報を記憶するメインメモリと、外部装置とのデータ入出力を制御するデータ入出力プロセッサと、を備える情報処理装置であって、
    前記第一のプロセッサは、
    新規タスクの実行要求を受け付ける実行要求受付け部と、
    前記新規タスクを処理するための所要プロセッサ数、所要処理時間、および所要バス帯域を特定するパラメータ特定部と、
    プロセッサごとに予約済みタスクの処理順を表すスケジュールファイルを参照し、前記新規タスクの所要プロセッサ数分のプロセッサにおける所要処理時間分の空き時間の有無、および当該空き時間における、前記新規タスクおよび同時に処理される予約済みタスクの総所要バス帯域が、前記情報処理装置の実装バス帯域を超えるか否かを確認して前記新規タスクの実行可否を判定する実行許可部と、
    前記新規タスクが実行可能と判定された場合、前記新規タスクの処理を起動する起動処理部と、を備え、
    前記実行許可部は、前記新規タスクが実行可能となるように、予約済みタスクを処理するプロセッサ、および各プロセッサにおける処理順の少なくともいずれかのスケジュールを調整し、
    前記所要バス帯域は、前記第一のプロセッサと前記メインメモリ間のデータ転送において前記新規タスクが必要とするバス帯域、前記第一のプロセッサと前記第二のプロセッサ間のデータ転送において前記新規タスクが必要とするバス帯域、および前記第一のプロセッサと前記データ入出力プロセッサ間のデータ転送において前記新規タスクが必要とするバス帯域のうち、少なくともひとつを含むことを特徴とする情報処理装置。
12. 前記第二のプロセッサはグラフィックプロセッサであり、前記第一のプロセッサによる制御により、取得した画像処理に係るデータに基づき画像処理演算を行うことを特徴とする請求項１１に記載の情報処理装置。
13. 前記実行許可部は、
    前記総所要バス帯域が実装バス帯域を超えた場合、
    前記新規タスクの優先度情報と前記予約済みタスクの優先度情報に基づいて前記新規タスクの実行可否を判定することを特徴とする請求項１１に記載の情報処理装置。
14. 前記第一のプロセッサと、前記第二のプロセッサと、前記データ入出力プロセッサとの間のバスにおいて、前記新規タスクおよび前記予約済みタスクがそれぞれ使用する帯域を前記優先度情報に基づいて調整するバス帯域制御部をさらに含むことを特徴とする請求項１３に記載の情報処理装置。
15. 前記実行許可部において前記新規タスクおよび前記予約済みタスクの一方が実行不可と判定された場合、ユーザが認識可能な表現にて前記新規タスクおよび前記予約済みタスクの一方が実行不可と判定された旨の通知をユーザに対し行う判定結果通知部をさらに含むことを特徴とする請求項１３に記載の情報処理装置。
16. 前記パラメータ特定部は、前記所要プロセッサ数、所要処理時間、および所要バス帯域の少なくともいずれかの情報の要求を、ネットワークを介して接続したサーバに対し発行するパラメータ要求発行部と、
    前記要求に応じて前記サーバが特定した情報を受信するパラメータ受信部と、
    を含むことを特徴とする請求項１１に記載の情報処理装置。
17. タスクごとに、前記所要プロセッサ数、所要処理時間、および所要バス帯域の少なくともいずれかの情報を、タスクのソフトウェアプログラムとは別に記憶したパラメータ記憶部をさらに含み、
    前記パラメータ特定部は、前記パラメータ記憶部を検索することにより、前記情報を特定することを特徴とする請求項１１に記載の情報処理装置。
18. タスクのソフトウェアプログラムを保持する装置から前記タスクを処理するための所要プロセッサ数、所要処理時間、および所要バス帯域の少なくともいずれかの情報の要求を受け付けるパラメータ要求受付け部と、
    前記要求に対し、前記情報を特定するパラメータ取得部と、
    特定した前記情報を前記装置へ送信するパラメータ送信部と、
    を含むことを特徴とするサーバ。

Images