JPWO2011111141A1 - リソース配分装置及びリソース配分方法並びにプログラム - Google Patents

Abstract

パラメータ決定部１１０は、複数のアプリケーション毎に、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を、リソース量Ｒと体感品質Ｑとの関係を示す式（１）の品質関数ｆに代入してパラメータａとｂを決定する。リソース量決定部１２０は、パラメータａとｂが決定されたアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定する。品質関数ｆ（ｘ）は、逆関数f−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものである。これにより、複数のアプリケーションに対してリソースを配分するために必要な、リソース量とユーザの体感品質との関係を示す品質関数を効率良く作成する。Ｑ＝ｆ（ｘ）＝ｆ（（Ｒ−ａ）／ｂ） （１）

Description

本発明は、コンピュータ上で動作する複数のアプリケーションへのリソースを配分する技術に関する。

コンピュータシステムにおけるリソースの配分について、様々な技術が提案されている。

例えば、特許文献１に開示されたＱｏＳ制御装置は、割当て量登録手段により、起動しているタスクについて予め定められた、ＱｏＳの等級に対応する資源の割当量をテーブルとして登録しておき、テーブルに基づいて各タスクへのリソース配分量を決定する。

また、特許文献２に開示された分散資源管理システムは、複数のアプリケーションで共有される資源を配分する際に、該複数のアプリケーションについて必要な注目資源の要求度を示す需要関数を作成し、これらの需要関数に基づいて資源の配分を行う。

携帯電話やＰＮＤ（Ｐｏｒｔａｂｌｅ Ｎａｖｉｇａｔｉｏｎ Ｄｅｖｉｃｅ）、ＤＰＦ（Ｄｉｇｉｔａｌ Ｐｈｏｔｏ Ｆｒａｍｅ）などの小型デバイスは、ＣＰＵの演算能力やメモリ容量などからなるリソースが限られているため、アプリケーションへのリソースの配分が特に重要である。これらの小型デバイスにおいて、起動されているアプリケーションの数が多いと、これらのアプリケーションは、期待通りに動作できない場合がある。これは、これらのアプリケーションが、限られたリソースを取り合うため、単体で動作するときに達成できる品質を得ることができないためである。

リソースが限られたデバイスで複数のアプリケーションを快適に動作させるには，リソースをこれらのアプリケーションに適切に配分する必要がある。起動されているアプリケーションの個数や種類によってリソースの適切な配分が異なるので、均等配分やベストエフォートで配分するなどの手法は好ましくない。

起動されている複数のアプリケーション毎の、該アプリケーションが使用するリソース量とユーザの体感品質との関係に基づいて、それぞれのアプリケーションに配分するリソース量を計算する手法が知られている。ユーザの体感品質とはユーザが感じる満足度の度合いであり、これを指標にリソース配分を行うことでユーザの満足度を高めることができる。

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

例えば、特許文献１に開示された技術を適用し、各アプリケーションについて、該アプリケーションが使用するリソース量と体感品質との関係を示すテーブルを予め登録しておき、起動された各アプリケーションの上記テーブルに基づいて、これらのアプリケーションに対してリソースの配分を行うことが考えられる。

また、アプリケーションが使用するリソース量と体感品質の関係を示すテーブルは、例えば、アプリケーションの製作者や、デバイスの設計者により予め作成することができる。

しかし、昨今の携帯電話機などは、小型デバイスといえども、数十個にもなるアプリケーションが実装されている場合がある。このように多数のアプリケーションが実装されたデバイスに対して、アプリケーション毎に、使用するリソース量と体感品質との関係を事前に調べることは、大変労力のかかる作業である。

本発明は、上記事情に鑑みてなされものであり、デバイス上で動作する複数のアプリケーションに対してリソース量の配分をする際に、夫々のアプリケーションが使用するリソース量と体感品質の関係を効率良く取得する技術を提供する。

本発明の１つの態様は、コンピュータ上で動作する複数のアプリケーションに対してリソース量の配分を行うリソース配分装置である。このリソース配分装置は、パラメータ決定部と、リソース量決定部を有する。

パラメータ決定部は、上記複数のアプリケーション毎に、使用するリソース量とユーザの体感品質との関係を示す式（１）の品質関数ｆにおける第１のパラメータａと第２のパラメータｂを決定する。具体的には、当該アプリケーションに対して、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を式（１）に代入することにより式（１）における第１のパラメータａと第２のパラメータｂを算出する。なお、品質関数ｆ（ｘ）は、逆関数f^−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものである。

Q＝f(x)＝f((R-a)/b) (1)
但し，
Ｑ：体感品質
ｆ：品質関数
Ｒ：リソース量
ａ：第１のパラメータ
ｂ：第２のパラメータ

リソース量決定部は、パラメータ決定部により第１のパラメータａと第２のパラメータｂが決定された上記複数のアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定する。

なお、上記態様のリソース配分装置を方法やシステムに置き換えて表現したもの、該リソース配分装置の動作をコンピュータに実行せしめるプログラム、該プログラムを記録したコンピュータ読取可能な記録媒体なども、本発明の態様としては有効である。

本発明にかかる技術によれば、複数のアプリケーションに対してリソースを配分するために必要な、使用するリソース量とユーザの体感品質との関係を示す品質関数を効率良く作成することができる。

本発明の第１の実施の形態にかかるリソース配分装置を示す図である。 品質関数ｆを示す図である。 品質関数ｆの２つの具体例を示す図である。 図１に示すリソース配分装置における処理の流れを示すフローチャートである。 アプリケーションの性能とリソース量の関係の例を示す図である。 図５に示す３つのアプリケーションに対して作成された品質関数を示す図である。 図５に示す３つのアプリケーションに対するリソース量の決定を説明するための図である。 本発明の第２の実施の形態にかかるリソース配分装置を示す図である。 図８に示すリソース配分装置における受付部の例を示す図である（その１）。 図８に示すリソース配分装置における受付部の例を示す図である（その２）。 図８に示すリソース配分装置における処理の流れを示すフローチャートである。 図８に示すリソース配分装置によるリソース量の配分の例を説明するための図である。 本発明の第３の実施の形態にかかるリソース配分装置を示す図である。 図１３に示すリソース配分装置によるリソース量の配分の例を説明するための図である。 図１３に示すリソース配分装置における処理の流れを示すフローチャートである。

以下、図面を参照して本発明の実施の形態について説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略、及び簡略化がなされている。また、様々な処理を行う機能ブロックとして図面に記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他の回路で構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。なお、各図面において、同一の要素には同一の符号が付されており、必要に応じて重複説明は省略されている。

また、上述したプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅ ｓｔｏｒａｇｅ ｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜第１の実施の形態＞
図１は、本発明の第１の実施の形態にかかるリソース配分装置１００を示す。このリソース配分装置１００は、携帯電話機などの小型デバイスに実装されており、該小型デバイス上で動作するアプリケーションのリソース配分を行う。

リソース配分装置１００は、パラメータ決定部１１０とリソース量決定部１２０を備える。

パラメータ決定部１１０は、該小型デバイスにて起動されている複数のアプリケーション毎に、使用するリソース量とユーザの体感品質との関係を示す式（２）の品質関数ｆにおける第１のパラメータａ_iと第２のパラメータｂ_iを決定する。

Ｑ_i＝ｆ（ｘ）＝ｆ（（Ｒ_i−ａ_i）／ｂ_i） （２）
但し，
ｉ：アプリケーションの番号
Ｑ_ｉ：体感品質
ｆ：品質関数
Ｒ_ｉ：リソース量
ａ_ｉ：第１のパラメータ
ｂ_ｉ：第２のパラメータ

図２に示すように、品質関数ｆ（ｘ）は、逆関数f^−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものである。

単調増加関数である品質関数ｆ（ｘ）として、（−∞，０）からなだらかに立ち上がり、ｘ＝０に近づくにつれ傾きが大きくなり、ｘ＝０を過ぎると次第に傾きが小さくなり、（＋∞，１）になだらかに近づいていく関数採用する。品質関数としてこの性質を持つ単調増加関数ｆ（ｘ）を用いるのは、仮定するユーザの体感品質の性質を再現できるからである。この仮定とは、ユーザは、性能が十分達成されている場合それ以上多少性能が上がったとしてもより品質が良くなったとは感じない一方、性能がほとんど達成されていない場合にさらに性能が下がってもより品質が悪くなったとは感じないというものである。なお、品質関数ｆ（ｘ）は連続的で滑らかであることが好ましいが、近似的に連続的で滑らかであっても良い。

図３は、品質関数ｆ（ｘ）の２つの具体例を示す。実線と点線は、式（３）と式（４）のｆ（ｘ）をそれぞれ示す。式（３）と式（４）における「ｘ」は、「（Ｒ−ａ）／ｂ」である。

以下において、ｆ（ｘ）の例として、式（３）が示すものを用いるが、品質関数は、式（３）に示す関数に限られることがない。

アプリケーション毎に、該アプリケーションの推奨リソース量Ｒ_ｉ ^ｈｉｇｈと該推奨リソース量Ｒ_ｉ ^ｈｉｇｈに対応する体感品質Ｑ_ｉ ^ｈｉｇｈ、及び、最低リソース量Ｒ_ｉ ^ｌｏｗと該最低リソース量Ｒ_ｉ ^ｌｏｗに対応する体感品質Ｑ_ｉ ^ｌｏｗを式（３）に代入すると下記の式（５）と式（６）を得ることができる。なお、Ｒ_ｉ ^ｈｉｇｈ、Ｑ_ｉ ^ｈｉｇｈ、Ｒ_ｉ ^ｌｏｗ、Ｑ_ｉ ^ｌｏｗは、アプリケーションの製作者又はデバイスの設計者により決定され、パラメータ決定部１１０に入力される。

そして、式（５）と式（６）を連立方程式としてａ_ｉとｂ_ｉについて解くと、式（７）と式（８）に示すように、第１のパラメータａ_ｉと第２のパラメータｂ_ｉを算出することができる。

パラメータ決定部１１０は、式（７）と式（８）に従って、アプリケーション毎に、第１のパラメータａ_ｉと第２のパラメータｂ_ｉを算出してリソース量決定部１２０に供する。

なお、Ｑ_ｉ ^ｈｉｇｈとＱ_ｉ ^ｌｏｗが下記の式（９）を満たす場合に、第１のパラメータａ_ｉと第２のパラメータｂ_ｉの算出は式（１０）と図（１１）が示すように簡単になる。

Ｑ_ｉ ^ｈｉｇｈ＋Ｑ_ｉ ^ｌｏｗ＝１ （９）

Ｑ_ｉ ^ｈｉｇｈとＱ_ｉ ^ｌｏｗが式（９）を満たす場合に、式（９）に示す第１のパラメータａ_ｉは、推奨リソース量Ｒ_ｉ ^ｈｉｇｈと最低リソース量Ｒ_ｉ ^ｌｏｗの平均値になる。これは、式（３）に示す品質関数ｆ（ｘ）に限らず、逆関数f^−１を有し、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものである如何なる単調増加関数の場合も成り立つ。この平均値は、品質Ｑが０．５である場合のリソース量を表す。

リソース量決定部１２０は、パラメータ決定部１１０により決定された各アプリケーションの第１のパラメータａと第２のパラメータｂを用いて、これらのアプリケーションに配分するリソース量を決定する。

本実施の形態において、リソース量決定部１２０は、各アプリケーションに配分するリソース量の総和が所定量ＴＲになり、かつ各アプリケーションの体感品質が同一になるように、夫々のアプリケーションに配分するリソース量を決定する。この体感品質を、以下均一体感品質ＡＱという。

具体的には、リソース量決定部１２０は、式（１２）と（１３）に従ってアプリケーション毎のリソース量Ｒｉを決定する。

Ｒ_ｉ＝ｂ_ｉｆ^−１（ＡＱ）＋ａ_ｉ （13）
但し，
ＡＱ：均一体感品質

なお、上記所定量ＴＲは、例えばデバイスの設計者によって設定される。具体的には、例えば、該小型デバイスのリソース量のうちの、アプリケーションの実行に使用可能なリソース量が決定できる。

図４は、図１に示すリソース配分装置１００における処理の流れを示すフローチャートである。
まず、パラメータ決定部１１０は、アプリケーション毎に、推奨リソース量Ｒ_ｉ ^ｈｉｇｈとそれに対応する体感品質Ｑ_ｉ ^ｈｉｇｈ、最低リソース量Ｒ_ｉ ^ｌｏｗとそれに対応する体感品質Ｑ_ｉ ^ｌｏｗを上述した式（５）と式（６）で示す連立方程式に代入して第１のパラメータａ_ｉと第２のパラメータｂ_ｉを算出する（Ｓ１００）。

リソース量決定部１２０は、パラメータ決定部１１０により算出された各アプリケーションの第１のパラメータａ_ｉと第２のパラメータｂ_ｉを式（１２）に代入して均一体感品質ＡＱを算出する（Ｓ１０２）。

そして、リソース量決定部１２０は、アプリケーション毎に、該アプリケーションの第１のパラメータａ_ｉ及び第２のパラメータｂ_ｉと、ステップＳ１０２で算出した均一体感品質ＡＱを式（１３）に代入して該アプリケーションに配分するリソース量Ｒｉを算出する（Ｓ１０４）。

ここで下記の具体例を用いて図１に示すリソース配分装置１００をより詳細に説明する。
例えば、配分の対象となるリソースがデバイスのＣＰＵ演算能力であり、アプリケーションに割り当て可能なリソース量（上述した所定量ＴＲ）が１００％である。起動されるアプリケーションは、Ｈ．２６４に準拠したデコーダ（以下Ｈ．２６４デコーダという）と、顔認識するアプリケーション（以下顔認識ＡＰという）と、ニュース閲覧のためのアプリケーション（以下ニュース閲覧ＡＰという）の３種類である。

Ｈ．２６４デコーダは，動画コーデックであるＨ．２６４フォーマットのファイルを復号するアプリケーションであり、顔認識ＡＰは、デバイスに備わっているカメラからの入力画像を解析し、顔が映っているか判断するアプリケーションである。ニュース閲覧ＡＰは、一定間隔でニュースを取得し表示するアプリケーションである。

また、上記３つのアプリケーションについて、使用するリソース量と性能の関係は、図５に示すように得られていたとする。図示の例では、Ｈ．２６４デコーダの性能は３０個のフレームの復号に所要する時間、顔認識ＡＰの性能は１フレームの解析に所要する時間、ニュース閲覧ＡＰの性能はニュースの取得間隔で表されている。

また、各アプリケーションについて、推奨リソース量Ｒ_ｉ ^ｈｉｇｈに対応する体感品質Ｑ_ｉ ^ｈｉｇｈが０．８、最低リソース量Ｒ_ｉ ^ｌｏｗがに対応する体感品質Ｑ_ｉ ^ｌｏｗが０．２であるとする。

パラメータ決定部１１０は、図５に示す性能とアプリケーションの関係を基に、推奨リソース量Ｒ_ｉ ^ｈｉｇｈと最低リソース量Ｒ_ｉ ^ｌｏｗを決定する。推奨リソース量Ｒ_ｉ ^ｈｉｇｈと最低リソース量Ｒ_ｉ ^ｌｏｗの決定は、例えば、Ｈ．２６４デコーダについては１秒に３０フレームを復号できれば十分、顔認識ＡＰについては０．５秒〜１秒程度で１フレームを解析したい、ニュース閲覧ＡＰについては１秒間隔でニュースを取得したいなどの基準に基づいてなされる。

このようにして、例えば、Ｈ．２６４デコーダについて、Ｒ_ｉ ^ｈｉｇｈとＲ_ｉ ^ｌｏｗはそれぞれ７０％、６０％、顔認識ＡＰについて、Ｒ_ｉ ^ｈｉｇｈとＲ_ｉ ^ｌｏｗはそれぞれ８０％、４０％であり、ニュース閲覧ＡＰについて、Ｒ_ｉ ^ｈｉｇｈとＲ_ｉ ^ｌｏｗはそれぞれ３０％、１０％に決定される。

パラメータ決定部１１０は、アプリケーション毎に、Ｑ_ｉ ^ｈｉｇｈ（ここでは０．８）、Ｒ_ｉ ^ｈｉｇｈ、Ｑ_ｉ ^ｌｏｗ（ここでは０．２）、Ｒ_ｉ ^ｌｏｗを式（５）と式（６）に代入して第１のパラメータａ_ｉと第２のパラメータｂ_ｉを解く。この例では、Ｈ．２６４デコーダについて、第１のパラメータａ_ｉと第２のパラメータｂ_ｉはそれぞれ６５と３．６になり、顔認識ＡＰについて、第１のパラメータａ_ｉと第２のパラメータｂ_ｉはそれぞれ６０と１４．４になり、第１のパラメータａ_ｉと第２のパラメータｂ_ｉはそれぞれ２０と７．２になる

そのため、Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰの品質関数は、図６に示すようになる。

そして、リソース量決定部１２０は、図６に示す各品質関数を用いて、夫々のアプリケーションに配分するリソース量を決定する。具体的には、まず、式（１２）に従って均一体感品質ＡＱを算出し、そして式（１３）により各アプリケーションへ配分するリソース量Ｒｉを算出する。なお、各アプリケーションへ配分するリソース量の総和が１００％である。

この例において、図７に示すように、均一体感品質ＡＱは０．１４になる。また、Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰには、それぞれ５９％、３４％、７％のリソース量が配分される。

このように、本実施の形態のリソース配分装置１００によれば、アプリケーションへリソース量を配分する際に、品質関数として上述した単調増加関数ｆ（ｘ）を用いるため、品質関数のパラメータを決定するために、１つのアプリケーションについて予め用意する必要のあるデータは、推奨リソース量Ｒ_ｉ ^ｈｉｇｈとそれに対応する体感品質Ｑ_ｉ ^ｈｉｇｈ、最低リソース量Ｒ_ｉ ^ｌｏｗとそれに対応する体感品質Ｑ_ｉ ^ｌｏｗのみである。そのため、品質関数の作成効率が向上し、アプリケーションの開発者やデバイスの設計者の負担と大幅に軽減することができる。なお、上記において図５に示すような、アプリケーションの性能とリソース量の関係に基づいてＲ_ｉ ^ｈｉｇｈとＲ_ｉ ^ｌｏｗを決定しているが、Ｒ_ｉ ^ｈｉｇｈとＲ_ｉ ^ｌｏｗそのものを直接パラメータ決定部１１０に供するようにしてもよい。

また、品質関数ｆ（ｘ）は、体感品質が最低リソース量付近で立ち上がり、推奨リソース量付近で立ち終わる特性を有するため、ユーザの直感に合わせたリソース配分ができる。

さらに、第１のパラメータａと第２のパラメータｂが決定された品質関数を用いてリソース量の配分を決定する際に、全ての組み合わせを探索せずに解析的に導くことができるため、計算コストを抑制することができる。そのため、リアルタイムに配分計算をしても、リソース量の配分にかかる計算オーバーヘッドを少なくすることができる。

＜第２の実施の形態＞
図８は、本発明の第２の実施の形態にかかるリソース配分装置２００を示す。リソース配分装置２００も、例えば携帯電話機などの小型デバイスに実装されており、該小型デバイス上で動作するアプリケーションのリソース配分を行う。

リソース配分装置２００は、パラメータ決定部２１０、受付部２２０、パラメータ調整部２３０、リソース量決定部２４０を備える。

パラメータ決定部２１０は、図１に示すリソース配分装置１００におけるパラメータ決定部１１０と同様の処理を行う。すなわち、パラメータ決定部２１０は、該小型デバイスにて起動されている複数のアプリケーション毎に、使用するリソース量とユーザの体感品質との関係を示す式（２）の品質関数ｆにおける第１のパラメータａ_iと第２のパラメータｂ_iを算出する。

パラメータ決定部２１０により算出された各アプリケーションの第１のパラメータａ_iと第２のパラメータｂ_iは、パラメータ決定部２１０からパラメータ調整部２３０に出力される。

受付部２２０は、アプリケーション毎に増減要求を入力可能なユーザインタフェースである。このユーザインタフェースは、夫々のアプリケーションに対して、ユーザがリソース量を増やしたいか減らしたいか、及び増減量を示す上記増減要求を入力するためのものである。

パラメータ調整部２３０は、パラメータ決定部２１０からの第１のパラメータａ_iと第２のパラメータｂ_iを調整し、調整後の第１のパラメータａ_iと第２のパラメータｂ_iをリソース量決定部２４０に出力する。パラメータ決定部２１０が得た第１のパラメータａ_iと第２のパラメータｂ_iと区別するために、パラメータ調整部２３０により調整後の第１のパラメータａ_iと第２のパラメータｂ_iをａ_i'とｂ_i'で表記する。

パラメータ調整部２３０は、受付部２２０を介してユーザが力した増減要求に応じて調整係数ｃ_iを決定すると共に、決定した調整係数ｃ_iを用いて式（１４）と式（１５）に示すように調整を行う。
ａ_i'＝ｃ_i×ａ_i （１４）
ｂ_i'＝ｃ_i×ｂ_i （１５）

調整係数ｃ_iは、全てのアプリケーションについて、デフォルト値が１である。ユーザにより増減要求の入力が無い場合に、パラメータ調整部２３０は、調整係数ｃ_iのデフォルト値を用いる。

すなわち、ユーザにより増減要求が無い場合に、ａ_i'とａ_iが同様であり、ｂ_i'とｂ_iが同様である。

パラメータ調整部２３０は、増減要求がリソース量の増加要求である場合に、１より大きく、かつ増加したい量が大きいほど大きい調整係数ｃ_iを第１のパラメータａ_ｉと第２のパラメータｂ_ｉに乗算し、増減要求がリソース量の減少要求である場合に、１より小さく、かつ減少したい量が大きいほど小さい調整係数ｃ_iを第１のパラメータａ_ｉと第２のパラメータｂ_ｉに乗算する。

図９は、増減要求を入力するための受付部２２０の一例を示す。図示のように、受付部２２０は、各アプリケーション（ＡＰ１、ＡＰ２、ＡＰ３、・・・）毎に、２つの調整ボタン（調整ボタン２２２と調整ボタン２２４）が設けられている。

調整ボタン２２２は、リソース量を増やしたい場合に押下するためのボタンであり、押下回数と増やしたい量とは正比例する。以下、調整ボタン２２２を増加ボタンという。

調整ボタン２２４は、リソース量を減らしたい場合に押下するためのボタンであり、押下回数と減らしたい量とは正比例する。以下、調整ボタン２２４を減少ボタンという。

パラメータ調整部２３０は、例えば、式（１６）と式（１７）に示すように、増加ボタン２２２の押下回数ｍ_iと減少ボタン２２４の押下回数ｎ_iに応じて調整係数ｃ_iを決定する。

ｃ_i＝１＋０．１×ｍ_i （１６）
但し、
ｍ_i：増加ボタン２２２の押下回数

ｃ_i＝１−０．１×ｎ_i （１７）
但し、
ｎ_i：減少ボタン２２４の押下回数

図１０は、受付部２２０の別の一例を示す。図示のように、各アプリケーション（ＡＰ１、ＡＰ２、ＡＰ３、・・・）毎に、調整バー２２６が設けられている。

パラメータ調整部２３０は、調整バー２２６がデフォルトの位置から上方に移動された場合に、移動された距離に応じた大きさの値を１に加算して調整係数ｃ_iを得、調整バー２２６がデフォルトの位置から下方に移動された場合に、移動された距離に応じた大きさの値を１から減算して調整係数ｃ_iを得る。

パラメータ調整部２３０は、アプリケーション毎に、第１のパラメータａ_ｉと第２のパラメータｂ_ｉに調整係数ｃ_iを乗算して得た第１のパラメータａ_i'と第２のパラメータｂ_i'をリソース量決定部２４０に出力する。増減要求が入力されていないアプリケーションについては、ａ_i'とａ_iが同様であり、ｂ_i'とｂ_iが同様である。

リソース量決定部２４０は、第１のパラメータと第２のパラメータとして調整後の第１のパラメータと調整後のパラメータを用いる点以外に、リソース配分装置１００における（１８）に従って各アプリケーションへ配分するリソース量を決定する。１３０と同様な演算により各アプリケーションへ配分するリソース量を決定する。

すなわち、本実施の形態において、品質関数は式（１８）に示すようになる。
Ｑ_i＝ｆ（ｘ）＝ｆ（（Ｒ_i−ａ_i'）／ｂ_i'） （１８）
＝ｆ（（Ｒ_i−ｃ_i×ａ_i）／ｃ_i×ｂ_i）
但し，
ｉ：アプリケーションの番号
Ｑ_ｉ：体感品質
ｆ：品質関数
Ｒ_ｉ：リソース量
ａ_i：調整前の第１のパラメータ
ｂ_i：調整前の第２のパラメータ
ａ_i'：調整後の第１のパラメータ
ｂ_i'：調整後の第２のパラメータ

なお、式（１８）は、下記式（１９）と同価である。
Ｑ_i＝ｆ（ｘ）＝ｆ（（Ｒ_i／ｃ_i−ａ_i）／ｂ_i） （１９）

式（１９）から分かるように、第１のパラメータａ_iと第２のパラメータｂ_iの値を調整した場合に得られる品質関数は、当初の推奨リソース量Ｒ_ｉ ^ｈｉｇｈ及び最低リソース量Ｒ_ｉ ^ｌｏｗにｃ_iを乗算した値で求めた品質関数と等価であり、ｃ_iは、推奨リソース量Ｒ_ｉ ^ｈｉｇｈ及び最低リソース量Ｒ_ｉ ^ｌｏｗをｃ_i倍するパラメータという意味を持つ。つまりｃ_iは、ある状況において当該アプリケーションがユーザにとってより重要である、または、重要ではない場合に、当初のリソース量配分量をその比率に応じ変更したい場合に設定するパラメータといえる。

図１１は、リソース配分装置２００における処理の流れを示すフローチャートである。まず、パラメータ決定部２１０は、アプリケーション毎に、推奨リソース量Ｒ_ｉ ^ｈｉｇｈとそれに対応する体感品質Ｑ_ｉ ^ｈｉｇｈ、最低リソース量Ｒ_ｉ ^ｌｏｗとそれに対応する体感品質Ｑ_ｉ ^ｌｏｗを上述した式（５）と式（６）で示す連立方程式に代入して第１のパラメータａ_ｉと第２のパラメータｂ_ｉを算出する（Ｓ１１０）。これらの第１のパラメータａ_ｉと第２のパラメータｂ_ｉは、パラメータ調整部２３０に入力される。

パラメータ調整部２３０は、受付部２２０を介してリソース量の増減が要求されていないアプリケーションに対して（Ｓ１１２：Ｎｏ）、その第１のパラメータａ_ｉと第２のパラメータｂ_ｉを調整せずにリソース量決定部２４０に出力する。

一方、受付部２２０を介してリソース量の増減が要求されたアプリケーションに対して（Ｓ１１２：Ｙｅｓ）、パラメータ調整部２３０は、該アプリケーションの第１のパラメータａ_ｉと第２のパラメータｂ_ｉに、増減要求に応じた調整係数を乗算して得た値をリソース量決定部２４０に出力する（Ｓ１１４）。

リソース量決定部２４０は、パラメータ調整部２３０からの調整後の第１のパラメータと第２のパラメータを用いて均一体感品質ＡＱを算出すると共に、各アプリケーションに対して、該均一体感品質ＡＱに対応するリソース量を該アプリケーションに配分するリソース量Ｒｉとして算出する（Ｓ１１６、Ｓ１１８）。

例えば、図５に示す３つのアプリケーション（Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰ）の場合、Ｈ．２６４デコーダに対して、ｃ_iが０．５になる増減要求が入力され、他の２つのアプリケーションに対して増減要求が入力されていないとする。

この場合、この３つのアプリケーションに対応する品質関数は、図１２に示すようになる。また、均一体感品質ＡＱは０．３７になり、Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰに配分されたリソース量は、それぞれ３２％、５２％、１６％になる。

この場合は、ある状況ではデコーダが重要ではなく、その性能は通常の半分である１５ｆｒａｍｅ／ｓｅｃで復号できれば十分である場合に相当する。リソース配分装置２００によれば、この場合におけるＨ．２６４デコーダへ配分するリソース量をリソース配分装置１００のときの５９％から３２％に減少し、減少分のリソースを他のアプリケーションに回すことができている。

すなわち、本実施の形態のリソース配分装置２００によれば、第１の実施の形態にかかるリソース配分装置１００と同様の効果を得ることができると共に、リソース量の配分にユーザの意図を反映させることができる。

＜第３の実施の形態＞
図１３は、本発明の第３の実施の形態にかかるリソース配分装置３００を示す。このリソース配分装置３００は、パラメータ決定部３１０と、リソース数制御部３２０と、リソース量決定部３３０を備える。

本実施の形態のリソース配分装置３００は、同種のリソースが複数存在する場合にアプリケーションに配分するリソースの個数を制御することができる。例えば、ＣＰＵコアが複数搭載されたデバイスにおいて、「ＣＰＵ演算能力」であるリソースがＣＰＵコアの数分存在することになる。

パラメータ決定部３１０は、リソース配分装置１００におけるパラメータ決定部１１０と同様の動作をし、各アプリケーションについて、第１のパラメータａ_ｉと第２のパラメータｂ_ｉを算出してリソース量決定部３３０に出力する。

リソース量決定部３３０は、パラメータ決定部３１０からの第１のパラメータａ_ｉと第２のパラメータｂ_ｉを用いて均一体感品質ＡＱを算出してリソース数制御部３２０に出力する。均一体感品質ＡＱの算出方法は、リソース配分装置１００における算出１３０の手法と同様であるが、この算出に際して用いられる、アプリケーションに配分するリソース量の総和となる所定量ＴＲは、リソース数制御部３２０から供給される。

リソース数制御部３２０は、同種の複数のリソースが存在する際に、均一体感品質ＡＱが予め定められた所定の閾値以上であることを条件に、アプリケーションに配分されるリソースの個数が最少個になるように制御を行うものである。分かりやすいように、図５に示す３つのアプリケーション（Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰ）が実装された場合を例に説明する。また、均一体感品質ＡＱの閾値が０．５に設定されているとする。

リソース数制御部３２０は、まず、１個のＣＰＵコアの演算能力（１００％）を所定量ＴＲとしてリソース量決定部３３０に供給する。

図１４に示すように、所定量ＴＲが１００％である場合に、リソース量決定部３３０が算出した均一体感品質ＡＱは、第１の実施の形態のリソース配分装置１００のときと同様に、０．１４である。それに対応して、Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰに配分されるリソース量Ｒｉも、第１の実施の形態のリソース配分装置１００のときと同様に、それぞれ５９％、３４％、７％である。

リソース数制御部３２０は、リソース量決定部３３０が算出した均一体感品質ＡＱと閾値（ここでは０．５）とを比較する。現在の均一体感品質ＡＱが０．１４であり、閾値より小さいため、リソース数制御部３２０は、所定量ＴＲを、ＣＰＵコアが２つである場合に対応する値（例えば２００％）に変更してリソース量決定部３３０に出力し、均一体感品質ＡＱの再計算を行わせる。

リソース量決定部３３０は、変更された所定量ＴＲを用いて均一体感品質ＡＱを再計算してリソース数制御部３２０に出力する。このときの均一体感品質ＡＱは、図１４に示すように、０．９になる。

均一体感品質ＡＱが閾値の０．５を超えたため、リソース数制御部３２０は、ＣＰＵコアの数を２つに決定して、リソース量決定部３３０にリソース量の配分決定を行わせる。図１４に示すように、０．９である均一体感品質ＡＱに対応して、Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰに配分されるリソース量Ｒｉは、７３％、９１％、３６％になる。

ところで、上記において算出されたリソース量Ｒｉ通りの配分は実際にできない場合がある。例えば、アプリケーションは並列化されておらずＣＰＵをまたいで実行できない場合に、２００％のリソース量を７３％、９１％、３６％の配分で配分することができない。

本実施の形態において、リソース量決定部３３０は、決定したリソース量をさらに配分可能に調整する機能を有する。例えば、各アプリケーションに対して、体感品質が閾値以上である前提下でリソース量を調整する。上記の例では、例えば、決定されたリソース量が最も大きい顔認識ＡＰに対してリソース量を１００％に変更し、Ｈ．２６４デコーダとニュース閲覧ＡＰについては、残りの１００％分を再配分する。これにより、調整後、Ｈ．２６４デコーダ、顔認識ＡＰ、ニュース閲覧ＡＰのリソース量は、７０％、１００％、３０％になる。

図１５は、リソース配分装置３００における処理の流れを示すフローチャートである。まず、パラメータ決定部３１０は、アプリケーション毎に、推奨リソース量Ｒ_ｉ ^ｈｉｇｈとそれに対応する体感品質Ｑ_ｉ ^ｈｉｇｈ、最低リソース量Ｒ_ｉ ^ｌｏｗとそれに対応する体感品質Ｑ_ｉ ^{ｌｏｗＱＬ}を上述した式（５）と式（６）で示す連立方程式に代入して第１のパラメータａ_ｉと第２のパラメータｂ_ｉを算出する（Ｓ１５０）。これらの第１のパラメータａ_ｉと第２のパラメータｂ_ｉは、リソース量決定部３３０に出力される。

リソース量決定部３３０は、各アプリケーションに配分するリソース量の総和が、１つのＣＰＵコアを使用する場合の所定量ＴＲになりように、均一体感品質ＡＱを算出してリソース数制御部３２０に出力する（Ｓ１５２）。

リソース数制御部３２０は、リソース量決定部３３０からの均一体感品質ＡＱが予め定められた閾値より小さい場合に（Ｓ１５４：Ｎｏ）、リソース数を１つ増やして、対応する所定量ＴＲをリソース量決定部３３０に出力する（Ｓ１５６）。

リソース量決定部３３０は、リソース数制御部３２０により再設定された所定量ＴＲを用いて均一体感品質ＡＱを再計算する（Ｓ１５２〜）。

ステップＳ１５２からの処理は、均一体感品質ＡＱが閾値以上になるまで繰り返される（Ｓ１５４：Ｎｏ、Ｓ１５６、Ｓ１５２〜）。

リソース量決定部３３０からの均一体感品質ＡＱが閾値以上になると（Ｓ１５４：Ｙｅｓ）、リソース数制御部３２０は、現在のリソース数を使用するリソース数として決定し、リソース量決定部３３０は、現在の均一体感品質ＡＱに対応する各アプリケーションのリソース量を決定する（Ｓ１６０）。

そして、決定されたリソース量通りの配分が可能な場合には（Ｓ１６２：Ｙｅｓ）、リソース量決定部３３０は、決定されたリソース量で配分を行う。一方、決定されたリソース量通りの配分ができない場合には（Ｓ１６２：Ｎｏ）、リソース量決定部３３０は、決定されたリソース量を配分可能に調整する（Ｓ１６４）。

本実施の形態のリソース配分装置３００によれば、リソース配分装置１００の効果を得ることができると共に、同種のリソースが複数存在する場合に、均一体感品質ＡＱが閾値以上である条件下で、リソースの数を最少にすることで、必要以上のリソース消費を抑えひいては消費電力の削減ができる。

以上、実施の形態をもとに本発明を説明した。実施の形態は例示であり、本発明の主旨から逸脱しない限り、上述各実施の形態に対して、さまざまな変更、増減、組合せを加えてもよい。これらの変更、増減、組合せが加えられた変形例も本発明の範囲にあることは当業者に理解されるところである。

この出願は、２０１０年３月１１日に出願された日本出願特願２０１０−０５４２８３を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明は、コンピュータ上で動作する複数のアプリケーションへのリソースの配分に利用できる。

１００ リソース配分装置 １１０ パラメータ決定部
１２０ リソース量決定部 ２００ リソース配分装置
２１０ パラメータ決定部 ２２０ 受付部
２２２ 増加ボタン ２２４ 減少ボタン
２３０ パラメータ調整部 ２２６ 調整バー
２４０ リソース量決定部 ２２２ 増ボタン
２２４ 減ボタン ２２６ 調整バー
３００ リソース配分装置 ３１０ パラメータ決定部
３２０ リソース数制御部 ３３０ リソース量決定部
ＡＱ 均一体感品質 ａ 第１のパラメータ
ｂ 第２のパラメータ ＴＲ 所定量

なお、Ｑ_ｉ ^ｈｉｇｈとＱ_ｉ ^ｌｏｗが下記の式（９）を満たす場合に、第１のパラメータａ_ｉと第２のパラメータｂ_ｉの算出は式（１０）と式（１１）が示すように簡単になる。

パラメータ決定部１１０は、アプリケーション毎に、Ｑ_ｉ ^ｈｉｇｈ（ここでは０．８）、Ｒ_ｉ ^ｈｉｇｈ、Ｑ_ｉ ^ｌｏｗ（ここでは０．２）、Ｒ_ｉ ^ｌｏｗを式（５）と式（６）に代入して第１のパラメータａ_ｉと第２のパラメータｂ_ｉを解く。この例では、Ｈ．２６４デコーダについて、第１のパラメータａ_ｉと第２のパラメータｂ_ｉはそれぞれ６５と３．６になり、顔認識ＡＰについて、第１のパラメータａ_ｉと第２のパラメータｂ_ｉはそれぞれ６０と１４．４になり、ニュース閲覧ＡＰについて、第１のパラメータａ_ｉと第２のパラメータｂ_ｉはそれぞれ２０と７．２になる。

リソース量決定部２４０は、第１のパラメータと第２のパラメータとして調整後の第１のパラメータと調整後の第２のパラメータを用いて、リソース量決定部１２０と同様な演算により各アプリケーションへ配分するリソース量を決定する。

リソース量決定部３３０は、パラメータ決定部３１０からの第１のパラメータａ_ｉと第２のパラメータｂ_ｉを用いて均一体感品質ＡＱを算出してリソース数制御部３２０に出力する。均一体感品質ＡＱの算出方法は、リソース配分装置１００におけるリソース量決定部１２０の手法と同様であるが、この算出に際して用いられる、アプリケーションに配分するリソース量の総和となる所定量ＴＲは、リソース数制御部３２０から供給される。

１００ リソース配分装置 １１０ パラメータ決定部
１２０ リソース量決定部 ２００ リソース配分装置
２１０ パラメータ決定部 ２２０ 受付部
２２２ 増加ボタン ２２４ 減少ボタン
２２６ 調整バー ２３０ パラメータ調整部
２４０ リソース量決定部 ３００ リソース配分装置
３１０ パラメータ決定部 ３２０ リソース数制御部
３３０ リソース量決定部 ＡＱ 均一体感品質
ａ 第１のパラメータ ｂ 第２のパラメータ
ＴＲ 所定量

Claims (7)

1. コンピュータ上で動作する複数のアプリケーションに対してリソース量の配分を行うリソース配分装置であって、
   前記複数のアプリケーション毎に、使用するリソース量とユーザの体感品質との関係を示す式（１）の品質関数ｆにおける第１のパラメータａと第２のパラメータｂを決定するパラメータ決定手段と、
   該パラメータ決定手段により前記第１のパラメータａと第２のパラメータｂが決定された前記複数のアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定するリソース量決定手段とを備え、
   前記パラメータ決定手段は、当該アプリケーションに対して、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を式（１）に代入することにより式（１）における第１のパラメータａと第２のパラメータｂを算出し、
   品質関数ｆ（ｘ）は、逆関数f^−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものであることを特徴とするリソース配分装置。
   Q＝f(x)＝f((R-a)/b) (1)
   但し，
   Ｑ：体感品質
   ｆ：品質関数
   Ｒ：リソース量
   ａ：第１のパラメータ
   ｂ：第２のパラメータ
2. 前記複数のアプリケーションのうちの任意のアプリケーションについて、リソース量の増減要求を受け付ける受付手段と、
   該任意のアプリケーションに対して前記パラメータ決定手段により決定された前記第１のパラメータａと第２のパラメータｂに、前記受付手段により受け付けられた増減要求が示す増加量に応じて増加する１より大きい倍数乗算し、前記受付手段により受け付けられた増減要求が示す減少量に応じて減少する１より小さい倍数を乗算するパラメータ調整手段をさらに有し、
   前記リソース量決定手段は、前記任意のアプリケーションに対して、前記パラメータ調整手段により前記第１のパラメータａと第２のパラメータｂが調整された品質関数ｆを用いて、該アプリケーションに配分するリソース量を決定することを特徴とする請求項１に記載のリソース配分装置。
3. 前記リソース量決定手段は、
   前記複数のアプリケーションに配分するリソース量の総和が所定量になり、かつ各アプリケーションの体感品質が同値の均一体感品質になるように、該複数のアプリケーションに配分するリソース量を決定することを特徴とする請求項１または２に記載のリソース配分装置。
4. 同種の複数のリソースが存在する際に、前記均一体感品質が予め定められた所定の閾値以上であることを条件に、前記複数のアプリケーションに配分されるリソースの個数が最少個になるように制御を行うリソース数制御手段をさらに備えることを特徴とする請求項３に記載のリソース配分装置。
5. 前記品質関数ｆ（ｘ）は、式（２）または式（３）であることを特徴とする請求項１から４のいずれか１項に記載のリソース配分装置。
   f(x)=1/(1+e^(-x)) (2)
   f(x)=(1/π)×arctan(x)+1/2 (3)
6. コンピュータ上で動作する複数のアプリケーションに対してリソース量の配分を行うリソース配分方法において、
   前記複数のアプリケーション毎に、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を、使用するリソース量Ｒとユーザの体感品質Ｑとの関係を示す式（４）の品質関数ｆに代入することにより第１のパラメータａと第２のパラメータｂを決定し、
   前記第１のパラメータａと第２のパラメータｂが決定された前記複数のアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定し、
   前記品質関数ｆ（ｘ）は、逆関数f^−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものであることを特徴とするリソース配分方法。
   Q＝f(x)＝f((R-a)/b) (4)
   但し，
   Ｑ：体感品質
   ｆ：品質関数
   Ｒ：リソース量
   ａ：第１のパラメータ
   ｂ：第２のパラメータ
7. コンピュータ上で動作する複数のアプリケーションに対してリソース量の配分を行う際に、
   前記複数のアプリケーション毎に、推奨リソース量と該推奨リソース量に対応する体感品質、及び、最低リソース量と該最低リソース量に対応する体感品質を、使用するリソース量Ｒとユーザの体感品質Ｑとの関係を示す式（５）の品質関数ｆに代入することにより第１のパラメータａと第２のパラメータｂを決定し、
   前記第１のパラメータａと第２のパラメータｂが決定された前記複数のアプリケーション毎の品質関数ｆを用いて、該複数のアプリケーションに配分するリソース量を決定する処理をコンピュータに実行させ、
   前記品質関数ｆ（ｘ）は、逆関数f^−１を有する単調増加関数であり、（−∞，０）と（＋∞，１）をつなぎ、ｘ＝０で点対称するものであることを特徴とするプログラムを記録した非一時的なコンピュータ可読媒体。
   Q＝f(x)＝f((R-a)/b) (5)
   但し，
   Ｑ：体感品質
   ｆ：品質関数
   Ｒ：リソース量
   ａ：第１のパラメータ
   ｂ：第２のパラメータ

Images