特表-13168293IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 富士通株式会社の特許一覧
再表2013-168293情報処理装置、電池残量通知方法および電池残量通知プログラム
<>
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000014
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000015
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000016
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000017
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000018
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000019
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000020
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000021
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000022
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000023
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000024
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000025
  • 再表WO2013168293-情報処理装置、電池残量通知方法および電池残量通知プログラム 図000026
< >
(19)【発行国】日本国特許庁(JP)
【公報種別】再公表特許(A1)
(11)【国際公開番号】WO/0
(43)【国際公開日】2013年11月14日
【発行日】2015年12月24日
(54)【発明の名称】情報処理装置、電池残量通知方法および電池残量通知プログラム
(51)【国際特許分類】
   G06F 1/28 20060101AFI20151201BHJP
   H02J 7/00 20060101ALI20151201BHJP
   H02J 1/00 20060101ALI20151201BHJP
   G06F 9/46 20060101ALI20151201BHJP
   G06F 9/50 20060101ALI20151201BHJP
【FI】
   G06F1/00 333C
   H02J7/00 302B
   H02J7/00 302D
   H02J1/00 307C
   H02J1/00 307F
   G06F9/46 350
   G06F9/46 462Z
【審査請求】有
【予備審査請求】未請求
【全頁数】65
【出願番号】特願2014-514338(P2014-514338)
(21)【国際出願番号】PCT/0/0
(22)【国際出願日】2012年5月11日
(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IS,JP,KE,KG,KM,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LT,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US,UZ,VC,VN,ZA
(71)【出願人】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】100074099
【弁理士】
【氏名又は名称】大菅 義之
(74)【代理人】
【識別番号】100133570
【弁理士】
【氏名又は名称】▲徳▼永 民雄
(72)【発明者】
【氏名】大石 亮介
【テーマコード(参考)】
5B011
5G065
5G503
【Fターム(参考)】
5B011DA06
5B011EA02
5B011GG03
5B011HH07
5G065AA01
5G065EA02
5G065GA04
5G065GA06
5G503AA01
5G503BA01
5G503BB01
5G503DA04
5G503DA13
5G503DA17
5G503EA05
5G503GD06
5G503GD07
(57)【要約】
電池101で駆動される情報処理装置100上では、ハイパーバイザが動作し、ハイパーバイザ上では、複数のオペレーティング・システム102aと102bが動作する。また、情報処理装置100は、評価部103と通知部104を有する。評価部103は、複数のオペレーティング・システム102aと102bそれぞれに対応する、電池101の仮想的な残量を評価する。評価には、オペレーティング・システム102aと102bそれぞれの特性を示す特性情報と、電池101の物理的な残量を示す物理残量値が用いられる。通知部104は、複数のオペレーティング・システム102aと102bそれぞれに、当該オペレーティング・システムに対応して評価部103が評価した値である仮想残量値を通知する。
【特許請求の範囲】
【請求項1】
電池で駆動される情報処理装置であって、
前記情報処理装置上で動作するハイパーバイザ上で動作する複数のオペレーティング・システムそれぞれの特性を示す特性情報と、前記電池の物理的な残量を示す物理残量値とを用いて、前記複数のオペレーティング・システムそれぞれに対応する、前記電池の仮想的な残量を評価する評価部と、
前記複数のオペレーティング・システムそれぞれに、当該オペレーティング・システムに対応して前記評価部が評価した値である仮想残量値を通知する通知部と
を備えることを特徴とする情報処理装置。
【請求項2】
前記複数のオペレーティング・システムそれぞれの前記特性情報が、
当該オペレーティング・システムおよび当該オペレーティング・システム上で動作するアプリケーションにより使用された資源の量を示す使用状況情報と、
当該オペレーティング・システムの優先度を示す優先度情報
のうち少なくとも一方を含むことを特徴とする請求項1に記載の情報処理装置。
【請求項3】
前記特性情報が前記使用状況情報を含み、
前記仮想残量値は、前記使用状況情報が示す前記量に対して単調増加する
ことを特徴とする請求項2に記載の情報処理装置。
【請求項4】
前記特性情報が、複数の期間のそれぞれと対応づけられた前記使用状況情報を含む
ことを特徴とする請求項2または3に記載の情報処理装置。
【請求項5】
前記特性情報が前記優先度情報を含み、
前記仮想残量値は、前記優先度情報が示す前記優先度に対して単調増加する
ことを特徴とする請求項2から4のいずれか1項に記載の情報処理装置。
【請求項6】
前記電池が充電中のとき、前記評価部は、前記複数のオペレーティング・システムのうち少なくとも1つ以上のそれぞれに対して、前記仮想残量値を、
当該オペレーティング・システムに対応する前記仮想残量値の定義域の最大値、または
前記物理残量値の定義域の最大値
と見なすことを特徴とする請求項1から5のいずれか1項に記載の情報処理装置。
【請求項7】
前記電池が充電中のとき、前記評価部は、
前記物理残量値が、前記物理残量値の定義域の最大値であると見なし、
前記最大値と見なした前記物理残量値を用いて、前記複数のオペレーティング・システムそれぞれに対応する前記仮想残量値を評価する
ことを特徴とする請求項1から5のいずれか1項に記載の情報処理装置。
【請求項8】
前記電池が充電中のとき、前記評価部は、前記複数のオペレーティング・システムのうち少なくとも1つ以上のそれぞれに対応する前記仮想残量値を、前記物理残量値と同じと見なす
ことを特徴とする請求項1から5のいずれか1項に記載の情報処理装置。
【請求項9】
前記物理残量値が第1の閾値未満のとき、前記評価部は、前記複数のオペレーティング・システムのうち少なくとも1つ以上のそれぞれに対応する前記仮想残量値をゼロと見なす
ことを特徴とする請求項1から8のいずれか1項に記載の情報処理装置。
【請求項10】
前記複数のオペレーティング・システムのうちの或るオペレーティング・システムに対応する前記仮想残量値が第2の閾値未満のとき、前記評価部は、前記或るオペレーティング・システムに対応する前記仮想残量値をゼロと再評価する
ことを特徴とする請求項1から8のいずれか1項に記載の情報処理装置。
【請求項11】
前記複数のオペレーティング・システムのそれぞれが動作する、前記ハイパーバイザ上の各仮想マシンに、前記ハイパーバイザが提供する仮想ハードウェアの構成を、前記ハイパーバイザが、
前記物理残量値、または
当該仮想マシン上の当該オペレーティング・システムに対応する前記仮想残量値
に応じて変更する
ことを特徴とする請求項1から10のいずれか1項に記載の情報処理装置。
【請求項12】
前記複数のオペレーティング・システムのうちの少なくとも1つに通知された前記仮想残量値に応じて、文字、画像、またはその組み合わせを表示する表示部
をさらに有することを特徴とする請求項1から11のいずれか1項に記載の情報処理装置。
【請求項13】
電池で駆動される情報処理装置が実行する電池残量通知方法であって、
前記情報処理装置上で動作するハイパーバイザ上で動作する複数のオペレーティング・システムそれぞれの特性を示す特性情報と、前記電池の物理的な残量を示す物理残量値とを用いて、前記複数のオペレーティング・システムそれぞれに対応する、前記電池の仮想的な残量を評価し、
前記複数のオペレーティング・システムそれぞれに、当該オペレーティング・システムに対応して前記電池の前記仮想的な残量を評価した値である仮想残量値を通知する
ことを特徴とする電池残量通知方法。
【請求項14】
前記ハイパーバイザ上で動作する、前記電池のデバイスドライバのレイヤにおいて、前記情報処理装置により実行されることを特徴とする請求項13に記載の電池残量通知方法。
【請求項15】
電池で駆動される情報処理装置に、
前記情報処理装置上で動作するハイパーバイザ上で動作する複数のオペレーティング・システムそれぞれの特性を示す特性情報と、前記電池の物理的な残量を示す物理残量値とを用いて、前記複数のオペレーティング・システムそれぞれに対応する、前記電池の仮想的な残量を評価し、
前記複数のオペレーティング・システムそれぞれに、当該オペレーティング・システムに対応して前記電池の前記仮想的な残量を評価した値である仮想残量値を通知する
ことを含む処理を実行させる電池残量通知プログラム。
【請求項16】
前記ハイパーバイザ上で動作する、前記電池のデバイスドライバのプログラムに含まれることを特徴とする請求項15に記載の電池残量通知プログラム。
【請求項17】
電池で駆動される情報処理装置が実行する構成変更方法であって、
前記電池の物理的な残量を監視し、
前記情報処理装置上で動作するハイパーバイザ上で動作する仮想マシンに前記ハイパーバイザが提供する仮想ハードウェアの構成を、前記電池の前記物理的な残量に応じて変更する
ことを特徴とする構成変更方法。
【請求項18】
電池で駆動される情報処理装置で使われるハイパーバイザのプログラムであって、前記情報処理装置に、
前記電池の物理的な残量を監視し、
前記ハイパーバイザ上で動作する仮想マシンに前記ハイパーバイザが提供する仮想ハードウェアの構成を、前記電池の前記物理的な残量に応じて変更する
ことを含む処理を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、電池で駆動される(battery-powered)情報処理装置に関する。
【背景技術】
【0002】
何らかの条件に応じて、情報処理装置の構成または動作を変更するための様々な技術が開発されている。
【0003】
例えば、情報処理装置の稼働中に、CPU(Central Processing Unit)やメモリなどのデバイスを、情報処理装置に動的に追加したり、情報処理装置から動的に削除したりする技術が知られている。当該技術は、「ホットプラグ(hot plug)」と呼ばれる。ホットプラグ機能によるデバイスの動的な追加または削除は、情報処理装置の負荷に応じて行われる場合もあるし、ユーザからのコマンド入力にしたがって行われる場合もある。
【0004】
ホットプラグ機能によるデバイスの動的な追加と削除は、それぞれ「ホットアド(hot-add)」および「ホットリムーブ(hot-remove)」とも呼ばれる。場合によっては、ホットアドが「ホットプラグ」と呼ばれ、ホットリムーブが「ホットアンプラグ(hot-unplug)」と呼ばれることもあるが、本明細書ではホットアドとホットリムーブを含む技術を「ホットプラグ」という。
【0005】
また、電池で駆動される装置においては、電池残量(remaining battery capacity)に応じた制御が行われることもある。例えば、予め決められたポリシと電池残量に応じて、デバイスへの電力供給やデバイスの動作周波数をオペレーティング・システムが制御することもある。
【0006】
電池で駆動される装置に関しては、消費される電力量(electrical energy)を抑制することがユーザの利便性向上につながる。よって、消費電力量を抑制するための様々な技術が提案されている。
【0007】
さらに、電池で駆動される情報処理装置の多くは、電池残量を表示する機能を有する。電池残量の表示を更新するタイミングや、より正確に電池残量を表示するための方法についても、様々な提案がなされている。
【0008】
例えば、複数のプログラムを実行する情報処理装置について、次のような技術が提案されている。
【0009】
当該情報処理装置は、記憶手段と検知手段と取得手段と実行手段を有する。記憶手段は、第1のプログラムが設定する状態情報、および第2のプログラムが設定するコールバック情報を、それぞれ対応づけて記憶する。また、検知手段は、第1のプログラムが設定する状態情報が変化したことを検知する。取得手段は、検知手段が第1のプログラムの状態が変化したことを検知した際に、第2のプログラムが設定するコールバック情報を取得する。実行手段は、コールバック情報に基づいてコールバックを呼び出す。
【0010】
例えば、記憶手段は、状態情報として、電池レベルの情報を記憶してもよく、コールバック情報として、電池レベルを通知するプログラムを記憶してもよい。この場合、実行手段は、コールバック情報に基づいて電池レベルを通知してもよい。
【0011】
また、消費電力量を抑制するための様々な技術が提案されている。例えば、仮想マシン機能により実行されるアプリケーションソフトウェアの終了処理が忘れられてしまうことにより、バッテリが消耗することがある。そのようなバッテリの消耗を抑制することを目的として、次のような携帯端末が提案されている。
【0012】
当該携帯端末には、タッチセンサ部が設けられている。タッチセンサ部は、当該携帯端末にユーザが触れていることを、検知することができる。
【0013】
そして、制御部にタッチセンサ部から接触信号が出力されているときは、「携帯端末がユーザにより使用中である」と判定される。逆に、非接触信号が出力されているときには、「携帯端末は現在使用されていない」と判定される。
【0014】
当該携帯端末上でアプリケーションソフトウェアが実行されているときに、タッチセンサ部から非接触信号が出力されたとき、制御部は、実行中のアプリケーションソフトウェアの実行を一時中断する。この一時中断により、携帯端末の消費電力量は抑えられる。
【0015】
さらに、仮想マシンシステムの消費電力量を仮想マシンごとに抑制できるようにするため、以下のような仮想マシンシステムも提案されている。
当該仮想マシンシステムにおいて、仮想バッテリ管理部は、仮想マシンへ仮想バッテリを提供する。また、仮想バッテリ管理部は、仮想マシンシステムの消費電力量を示す消費電力量ポリシ、仮想マシンへの充電量を示す充電量ポリシ、仮想マシンへの電力の配分率を示す電力配分テーブルを設定する。
【0016】
そして、スケジュール管理部が、仮想マシンへリソースを割り当てる。当該仮想マシンシステムにおいては、仮想マシンへのリソース割り当て量が、リソース割り当て量管理部から得られる。
【0017】
仮想マシンが駆動中であれば、消費電力量ポリシと電力配分テーブルを参照してCPU使用時間を放電量に換算して仮想バッテリの残量を減少させる処理が行われる。逆に、仮想マシンが停止中であれば、充電量ポリシと電力配分テーブルを参照して停止時間を充電量に換算して仮想バッテリの残量を増加させる処理が行われる。
【先行技術文献】
【特許文献】
【0018】
【特許文献1】特開2008−234494号公報
【特許文献2】特開2007−221228号公報
【特許文献3】特開2010−33207号公報
【非特許文献】
【0019】
【非特許文献1】Mwaikambo, Z., Raj, A., Russell, R., Schopp, J., and Vaddagiri, S., "Linux Kernel Hotplug CPU Support", Proceedings of the Linux Symposium, 2004, Vol. 2, pp. 467-480.(なおLinuxは登録商標)
【発明の概要】
【発明が解決しようとする課題】
【0020】
何らかのポリシにしたがって、電池の残量に応じて、適切に電力を使用するための電源管理機能は、様々なオペレーティング・システムに実装されている。
【0021】
一方で、1台の情報処理装置上で複数のオペレーティング・システムが動作することもある。具体的には、情報処理装置上でハイパーバイザが動作し、ハイパーバイザ上で複数のオペレーティング・システムが動作することもある。このようにハイパーバイザ上で複数のオペレーティング・システムが動作する環境においては、個々のオペレーティング・システムが互いに独立に電源管理を行うと、情報処理装置全体としては、適切に電力が使用されないおそれがある。
【0022】
本発明は、1つの側面では、ハイパーバイザ上で複数のオペレーティング・システムが動作する場合にも、情報処理装置全体として適切に電力が使用されるようにすることを目的とする。
【課題を解決するための手段】
【0023】
一態様による情報処理装置は、電池で駆動され、評価部と通知部を有する。また、前記情報処理装置上で動作するハイパーバイザ上では、複数のオペレーティング・システムが動作する。
【0024】
前記評価部は、前記複数のオペレーティング・システムそれぞれの特性を示す特性情報と、前記電池の物理的な残量を示す物理残量値とを用いて、前記複数のオペレーティング・システムそれぞれに対応する、前記電池の仮想的な残量を評価する。そして、前記通知部は、前記複数のオペレーティング・システムそれぞれに、当該オペレーティング・システムに対応して前記評価部が評価した値である仮想残量値を通知する。
【発明の効果】
【0025】
上記の情報処理装置によれば、ハイパーバイザ上で複数のオペレーティング・システムが動作する場合にも、情報処理装置全体として適切に電力が使用される。
【図面の簡単な説明】
【0026】
図1】第1実施形態の情報処理装置のブロック構成図である。
図2】情報処理装置のハードウェア構成の例を示す図である。
図3】第2実施形態の情報処理装置のブロック構成図である。
図4】第2実施形態で使われるプロファイルの例を示す図である。
図5】第2実施形態で使われるルールセットの例を示す図である。
図6】第2実施形態の情報処理装置が行う処理のフローチャート(その1)である。
図7】第2実施形態の情報処理装置が行う処理のフローチャート(その2)である。
図8】第2実施形態において履歴を使わずに仮想残量値を計算する例を示す図である。
図9】第2実施形態において履歴を使って仮想残量値を計算する例を示す図である。
図10】第3〜第5実施形態で使われる割り当てルールの例を示す図である。
図11】第3実施形態でハイパーバイザが行う処理のフローチャートである。
図12】第4〜第5実施形態でハイパーバイザが行う処理のフローチャートである。
図13】仮想ハードウェアの動的な構成変更の効果を説明する図である。
【発明を実施するための形態】
【0027】
以下、実施形態について、図面を参照しながら詳細に説明する。具体的には、まず図1を参照して第1実施形態について説明する。次に、図2を参照して、第1〜第5実施形態のいずれも適用可能な情報処理装置のハードウェア構成の例を説明する。その後、図3〜9を参照して第2実施形態について説明する。さらに、図10〜11を参照して第3実施形態について説明し、図10と12を参照して第4実施形態について説明し、第5実施形態についても図10と12を参照して説明する。また、第3〜第5実施形態の効果について図13を参照して説明する。最後に、その他の変形例についても説明する。
【0028】
図1は、第1実施形態の情報処理装置のブロック構成図である。図1の情報処理装置100は、電池101で駆動される。電池101は、1次電池でもよいし、充電可能な2次電池でもよい。
【0029】
電池101で駆動される情報処理装置100は、具体的には、例えば、以下の(1a)〜(1g)のいずれの種類であってもよい。
【0030】
(1a)ノート型PC(Personal Computer)
(1b)タブレット端末
(1c)PDA(Personal Digital Assistant)
(1d)スマートフォン
(1e)携帯電話
(1f)携帯型メディアプレーヤ
(1g)その他の各種携帯端末
【0031】
また、情報処理装置100は、ハイパーバイザを用いて仮想化されており、ハイパーバイザ上で複数のオペレーティング・システム(以下「OS」と略す)が動作する(run)。より詳しくは、情報処理装置100上でハイパーバイザが動作し、ハイパーバイザ上で複数の仮想マシンが動作し、各仮想マシン上で各OSが動作する。
【0032】
例えば、図1には、2つのOS102aと102bが例示されているが、OSの数(すなわち仮想マシンの数)は、実施形態に応じて任意である。なお、図1では仮想マシンは省略されている。
【0033】
また、情報処理装置100は、評価部103と通知部104を有する。
評価部103は、複数のOS(例えばOS102aと102b)それぞれに対応する、電池101の仮想的な残量を評価する。以下では、評価部103が評価した値を「仮想残量値」という。評価部103は、具体的には、複数のOS(例えばOS102aと102b)それぞれの特性を示す特性情報と、電池101の物理的な残量を示す値(以下、「物理残量値」という)を用いて、各仮想残量値を評価する。ある観点から見れば、特性情報は、各仮想マシンの特性を示す情報でもある。
【0034】
通知部104は、OS102aに対応して評価部103が評価した仮想残量値を、OS102aに通知する。また、通知部104は、OS102bに対応して評価部103が評価した仮想残量値を、OS102bに通知する。
【0035】
情報処理装置100は、評価部103が評価に用いる特性情報と物理残量値をそれぞれ取得するための、第1の取得部105と第2の取得部106をさらに有していてもよい。
【0036】
第1の取得部105は、各OSの特性を示す特性情報を取得する。特性情報は、静的に予め決められた情報でもよいし、動的に変化する情報でもよいし、両者の組み合わせでもよい。
【0037】
換言すれば、第1の取得部105は、情報処理装置100の不図示の記憶装置に記憶された静的な特性情報を、記憶装置から読み取ってもよい。それにより、第1の取得部105は、静的な特性情報を記憶装置から取得してもよい。
【0038】
あるいは、第1の取得部105は、OS102aおよび102b(ならびに、OS102aおよび102b上で動作するアプリケーション)の実際の動作(activity)に基づいて、動的な特性情報を生成してもよい。換言すれば、第1の取得部105は、各仮想マシンの実際の動作に基づいて、動的な特性情報を生成してもよい。それにより、第1の取得部105は、動的な特性情報を取得してもよい。
【0039】
例えば、OS102aの特性情報は、以下の(2a)と(2b)に示す2種類の情報のうち少なくとも一方を含んでもよい。
【0040】
(2a)OS102a、およびOS102a上で動作するアプリケーションにより使用された、資源の量を示す使用状況情報。
(2b)OS102aの優先度を示す優先度情報。
【0041】
同様に、OS102bの特性情報は、以下の(3a)と(3b)に示す2種類の情報のうち少なくとも一方を含んでもよい。
【0042】
(3a)OS102b、およびOS102b上で動作するアプリケーションにより使用された、資源の量を示す使用状況情報。
(3b)OS102bの優先度を示す優先度情報。
【0043】
使用状況情報は動的な特性情報の例であり、優先度情報は静的な特性情報の例である。
なお、使用状況情報によって使用量が示される資源は、具体的には電力資源であってもよい。例えば、ある期間で消費される電力量または当該期間での推定平均電力を示す値が、使用状況情報として使われてもよい。
【0044】
あるいは、使用状況情報によって使用量が示される資源は、情報処理装置100が有するハードウェア資源であってもよいし、情報処理装置100から使用可能なネットワーク資源であってもよい。
【0045】
例えば、消費電力量に関するOS102aの特性を表す特性情報は、具体的には、「OS102a(およびOS102a上のアプリケーション)によって、ハードウェア資源やネットワーク資源がどれほど使用されたか」を示す使用状況情報を含んでもよい。OS102a(およびOS102a上のアプリケーション)に起因する消費電力量は、OS102a(およびOS102a上のアプリケーション)によって使用された資源の量に依存する。よって、上記のような使用状況情報は、間接的に、消費電力量に関するOS102aの特性(換言すれば、OS102aの動作する仮想マシンの特性)を表す。
【0046】
使用状況情報は、ある特定の1つの期間(例えば、長さが1分間の直近の期間)において各OS(およびOS上のアプリケーション)がどれほど資源を使用したかを示してもよい。
【0047】
あるいは、情報処理装置100は、使用状況情報の履歴を図1には不図示の記憶部に記憶していてもよい。そして、評価部103は、仮想残量値の評価に際して、使用状況情報の履歴を用いてもよい。換言すれば、特性情報は、複数の期間のそれぞれと対応づけられた使用状況情報を含んでもよい。
【0048】
さて、第2の取得部106は、電池101の物理的な残量を示す物理残量値を取得する。
【0049】
評価部103は、複数のOSそれぞれの特性情報と、物理残量値とを用いて、複数のOSそれぞれに対応する仮想残量値を評価する。また、通知部104は、上記のとおり、各OSに仮想残量値を通知する。
【0050】
なお、評価部103は、予め決められた数式にしたがって、特性情報と物理残量値から仮想残量値を計算してもよい。つまり、評価部103は、計算によって仮想残量値を評価してもよい。
【0051】
あるいは、特性情報は、複数の物理残量値にそれぞれ仮想残量値を対応づける換算表のような情報であってもよい。この場合、評価部103は、第2の取得部106により取得された物理残量値と対応づけられている仮想残量値を換算表から読み取ることにより、仮想残量値を評価してもよい。もちろん、評価部103は、換算表と補間計算によって仮想残量値を評価してもよい。
【0052】
さて、OS102aに仮想残量値が通知されると、OS102aは、予め設定された電源管理のためのポリシにしたがって、通知された仮想残量値に応じて、適宜に電源を管理する。例えば、OS102aは、ディスプレイの明るさを調整するための命令を発行してもよいし、CPUのクロック周波数を調整するための命令を発行してもよい。これらの命令は、具体的には、ハイパーバイザコールであってもよい。
【0053】
OS102aに設定される電源管理のためのポリシは、例えば、以下の(4a)〜(4c)のポリシのうちのいずれか1つであってもよい。
【0054】
(4a)パフォーマンスを低下させて消費電力量を抑えることで、電池101を長持ちさせるための、「省電力」ポリシ。
(4b)消費電力量の増加には構わず、パフォーマンスを向上させるための、「ハイパフォーマンス」ポリシ。
(4c)両者のバランスをとった、「バランス」(balanced)ポリシ。
【0055】
同様に、OS102bに仮想残量値が通知されると、OS102bは、予め設定された電源管理のためのポリシ(例えば(4a)〜(4c)のいずれかのポリシでもよい)にしたがって、通知された仮想残量値に応じて、適宜の省電力制御を実行する。
【0056】
なお、仮想残量値は特性情報に依存するので、OS102aに通知される仮想残量値とOS102bに通知される仮想残量値は、必ずしも同じではない。
【0057】
また、OS102aに設定されたポリシとOS102bに設定されたポリシも、必ずしも同じではない。例えば、以下の(5a)や(5b)のような場合があり得る。
【0058】
(5a)OS102aは「省電力」ポリシにしたがって電源を管理する一方で、OS102bは「ハイパフォーマンス」ポリシにしたがって電源を管理する場合。
(5b)OS102aと102bの両者とも「省電力」ポリシにしたがって電源を管理するものの、OS102aの「省電力」ポリシを規定するパラメタの値と、OS102bの「省電力」ポリシを規定するパラメタの値が異なる場合。
【0059】
いずれにしろ、OS102aと102bは独立に、それぞれのポリシにしたがって、それぞれに通知された仮想残量値に応じて適宜の制御を行う。
【0060】
ところで、評価部103による評価の詳細は、情報処理装置100全体についての電源管理のためのポリシに応じて、様々であってよい。情報処理装置100全体についての電源管理のためのポリシは、OS102aと102bそれぞれのポリシとは別に定義される。情報処理装置100全体についての電源管理のためのポリシは、例えば、以下の(6a)〜(6c)のポリシのうちのいずれか1つであってもよい。
【0061】
(6a)「OS102aと102bの双方を含む情報処理装置100全体として、ハイパフォーマンスが達成されることが好ましい」というポリシ。
(6b)「電池101をなるべく長持ちさせることが好ましい」というポリシ。
(6c)両者のバランスをとったポリシ。
【0062】
評価部103は、情報処理装置100全体についての電源管理のためのポリシに応じて決められた適宜の式にしたがって、各OSの仮想残量値を計算してもよい。
【0063】
特性情報が使用状況情報を含む場合、仮想残量値は、使用状況情報が示す資源使用量に対して単調増加するよう定義されていてもよい。特性情報が優先度情報を含む場合、仮想残量値は、優先度情報が示す優先度に対して単調増加するよう定義されていてもよい。
【0064】
また、評価部103は、特定の条件下では、当該特定の条件が成立しない場合とは異なる方法で、仮想残量値を評価(あるいは再評価)してもよい。特定の条件の例は、例えば以下の(7a)〜(7c)の条件である。
【0065】
(7a)「電池101が充電中である」という条件。
(7b)「物理残量値が閾値未満である」という条件。
(7c)「評価部103により得られた仮想残量値が、閾値未満である」という条件。
【0066】
例えば、電池101が充電中のとき、評価部103は、複数のOSのうち少なくとも1つ以上のそれぞれに関して、「仮想残量値は、物理残量値の定義域の最大値に等しい」と見なしてもよい。つまり、この場合、通知部104は、複数のOSのうち少なくとも1つ以上のそれぞれに対して、物理残量値の定義域の最大値を、仮想残量値として通知する。
【0067】
例えば、物理残量値がWh(ワット時)単位で表されてもよい。この場合、物理残量値の定義域の最大値は、電池101の仕様で定められている値(具体的には、フル充電された状態から電池101が供給することのできる電力量を示す値)であってもよい。
【0068】
あるいは、物理残量値がパーセンテージで表されてもよい。この場合、物理残量値の定義域の最大値は100である。
【0069】
以上のように、電池101が充電中のとき、実際の物理残量値によらず、物理残量値の定義域の最大値が、仮想残量値として通知されてもよい。
【0070】
ところで、複数のOSのうち少なくとも1つ以上のそれぞれに関して、当該OSに対応する仮想残量値の定義域の最大値が定義されていてもよい。例えば、特性情報が優先度情報を含む場合、優先度情報と、物理残量値の定義域の最大値とに応じて、仮想残量値の定義域の最大値が定義されていてもよい。そして、電池101が充電中のとき、もし、或るOSに関して仮想残量値の定義域の最大値が定義されているならば、評価部103は、当該OSに対応する仮想残量値を、仮想残量値の定義域の最大値と見なしてもよい。
【0071】
あるいは、電池101が充電中のとき、評価部103は、実際の物理残量値とは関係なく、「物理残量値は、物理残量値の定義域の最大値である」と見なしてもよい。そして、評価部103は、このようにして最大値と見なした物理残量値を用いて、複数のOSそれぞれに対応する仮想残量値の評価を行ってもよい。
【0072】
または、電池101が充電中のとき、評価部103は、複数のOSのうち少なくとも1つ以上のそれぞれに対応する仮想残量値を、物理残量値と同じであると見なしてもよい。
【0073】
また、物理残量値が第1の閾値未満のとき、評価部103は、複数のOSのうち少なくとも1つ以上のそれぞれに関して、「仮想残量値がゼロである」と見なしてもよい。つまり、この場合、通知部104は、複数のOSのうち少なくとも1つ以上のそれぞれに対して、「仮想残量値がゼロである」と通知する。
【0074】
複数のOSのうちの或るOSに対応する仮想残量値が第2の閾値未満のとき、評価部103は、「当該或るOSに対応する仮想残量値はゼロである」と再評価してもよい。つまり、この場合、通知部104は、当該或るOSに対して、「仮想残量値がゼロである」と通知する。
【0075】
なお、情報処理装置100は、不図示の表示部をさらに有していてもよい。表示部は、複数のOSのうちの少なくとも1つに通知された仮想残量値に応じて、文字、画像、またはその組み合わせを表示する。表示部は、例えば、「70%」のように文字列により仮想残量値を表示してもよい。または、表示部は、例えば、仮想残量値を3個のレベルで示すアイコンを表示してもよい。
【0076】
以上説明した情報処理装置100の動作は、情報処理装置100内のプロセッサが所定のプログラムを実行することによって実現されてもよい。当該所定のプログラムは、例えば、電池101のデバイスドライバのプログラムに含まれていてもよいし、ハイパーバイザのプログラムの中に含まれていてもよい。電池101のデバイスドライバは、具体的には、ハイパーバイザで動作する。
【0077】
以上説明した図1の情報処理装置100によれば、ハイパーバイザ上で複数のOSが動作する場合にも、情報処理装置100全体として適切に電力が使用される。以下に、2つの比較例(便宜上、「第1比較例」と「第2比較例」という)と図1の情報処理装置100との比較を通じて、情報処理装置100の利点について説明する。
【0078】
第1および第2比較例では、第1実施形態のように通知部104がOSごとに仮想残量値を通知するのではなく、ハイパーバイザがどのOSにも同じ物理残量値を通知するものとする。つまり、第1および第2比較例には、評価部103も通知部104も第1の取得部105も第2の取得部106も存在しない。
【0079】
ところで、各OSは、当該OSに物理残量値が通知されたのか、それとも当該OSに仮想残量値が通知されたのかを認識しない。よって、図1の第1実施形態においても、第1および第2比較例においても、各OSは、単に「電池の残量を示す値が通知された」と認識する。
【0080】
また、各OSは、「他のOSがどのようなポリシにしたがって電源を管理するか」ということに関与しない。換言すれば、複数のOSは独立に電源を管理する。
そして、或るOSのポリシと別のOSのポリシは異なる場合があり得る。また、たとえ複数のOSにおいて互いに似たポリシが使われているとしても、或るOSのポリシを規定するパラメタの値が、別のOSのポリシを規定するパラメタの値とは異なる場合もあり得る。
【0081】
第1比較例と第1実施形態では、このようにOSごとにポリシまたはパラメタが異なることがあり得る。第2比較例では逆に、全OSがまったく同じポリシにしたがって電源を管理するものとする。
【0082】
第1比較例では、同じ物理残量値が全OSに通知されるため、情報処理装置100全体としては適切に電力が使われないことがあり得る。説明の便宜上、例えば以下の(8a)〜(8e)のように仮定する。
【0083】
(8a)第1比較例においても、2つのOS102aと102bがハイパーバイザ上で動作する。
(8b)OS102aには、「電池101の残量が30%以上なら通常モードで動作し、電池101の残量が30%未満なら省電力モードで動作する」というポリシが設定されている。
(8c)OS102bには、「電池101の残量が10%以上なら通常モードで動作し、電池101の残量が10%未満なら省電力モードで動作する」というポリシが設定されている。
(8d)通常モードは、パフォーマンスの向上を消費電力量の抑制よりも優先するモードである。
(8e)省電力モードは、消費電力量の抑制をパフォーマンスの向上よりも優先するモードである。
【0084】
以上の(8a)〜(8e)の仮定のもとで、仮に物理残量値が20%であったとする。すると、第1比較例においては、OS102aが省電力モードで動作する一方、OS102bは通常モードで動作する。通常モードで動作するOSが存在すると、消費電力量は比較的大きい。その結果、第1比較例では、「OS102aは電池101を長持ちさせるために省電力モードで動作しているにも関わらず、意図通りには電池101は長持ちしない」という事態が生じ得る。
【0085】
あるいは、(8a)〜(8e)の仮定のもとで、仮に物理残量値が50%であったとする。すると、第1比較例においては、OS102aと102bの双方が通常モードで動作するので、電池残量がすぐに減ってしまう。
【0086】
一方、OS102aと102bは、電源管理のために電池101の残量が0%になるまでにかかる時間を予測してもよいが、第1比較例ではこの予測の精度が悪いことがある。例えば、以上のようにしてOS102aと102bの双方が通常モードで動作するせいで、「予測された時間よりも遥かに短い時間のうちに、物理残量値がゼロになってしまう」という事態が生じることがあるからである。
【0087】
このように、第1比較例では、情報処理装置100全体として適切に電力が使われないおそれがある。そこで、第1比較例における問題(つまり、意図しない事態や予測精度の低さといった問題)を避けるために、第2比較例を採用することも可能である。しかし、第2比較例は、あまり好ましくない。
【0088】
なぜなら、第2比較例では、全OSがまったく同じポリシにしたがって電源を管理するので、OSごとの柔軟な電源管理が制約を受けてしまうからである。つまり、ハイパーバイザによる仮想化のメリットの1つは各OSの独立性であるのに、第2比較例ではOSに応じた柔軟な管理が阻害されてしまう。
【0089】
また、全OSに共通のポリシに、どのOSの特性も必ず適しているとは限らない。共通のポリシに適さない特性を持ったOSが存在する場合もあり得る。そのため、第2比較例では、情報処理装置100全体として、必ずしも電力が適切には使用されないことがあり得る。
【0090】
以上のような第1および第2比較例と比べると、第1実施形態には、次の(9a)と(9b)のような利点がある。
【0091】
(9a)評価部103が適宜のポリシ(例えば(6a)〜(6c)のうちのいずれか)にしたがって仮想残量値を評価すれば、情報処理装置100全体としては適切に電力が使われる。
(9b)OSごとの独立性を犠牲にしなくてよい。換言すれば、OSごとの柔軟な電源管理は制約を受けない。
【0092】
ところで、上記に例示した(4a)〜(4c)のポリシのように、各OSに設定される具体的なポリシは様々である。しかし、多くのポリシは、「電池の残量が多い場合には、電池の残量が少ない場合と比べると、パフォーマンスの向上がより重視される」という点において共通である。換言すれば、多くのポリシは、「電池の残量が少ない場合には、電池の残量が多い場合と比べると、消費電力量の抑制がより重視される」という点において共通である。
【0093】
したがって、第1実施形態において、OSの優先度が高いほど評価部103が仮想残量値を高く評価すれば、以下の(10a)と(10b)のことが期待される。
【0094】
(10a)優先度の高いOSは、パフォーマンスの向上を重視して動作する。
(10b)優先度の低いOSは、消費電力量の抑制を重視して動作する。
【0095】
よって、情報処理装置100全体として、適切にOS間で電力が配分される。また、各OSは、第2比較例のように一律なポリシにしたがって動作するのではなく、当該OS独自のポリシにしたがって動作するので、柔軟性も保たれる。
【0096】
また、第1実施形態において、より多くの電力量を消費する高負荷の仮想マシンのOSほど、評価部103が仮想残量値を高く評価すれば、以下の(11a)と(11b)のことが期待される。
【0097】
(11a)負荷の高い(したがって消費電力量が大きい)仮想マシンのOSは、パフォーマンスの向上を重視して動作する。
(11b)負荷の低い(したがって消費電力量が小さい)仮想マシンのOSは、消費電力量の抑制を重視して動作する。
【0098】
よって、仮想マシンの負荷が高いほど、当該仮想マシン上のOSに対応する仮想残量値を評価部103が高く評価することが好ましい。そのような評価の結果として、高負荷の仮想マシンのOSが「電池の残量が十分にあるので、パフォーマンスの向上を重視して構わない」と認識する期間を、例えば第1比較例と比べて長引かせることも可能である。換言すれば、仮想残量値が負荷に対して単調増加する場合、高負荷の仮想マシンのOS上で実行中のプロセスは、消費電力量を抑制するための制約を受けずに(あるいは、そのような制約をあまり受けずに)順調に実行され、ハイパフォーマンスが達成される。
【0099】
なお、評価部103は、上記のように負荷の高さに応じて仮想残量値を評価する場合、負荷の高さを複数のOS間で(換言すれば複数の仮想マシン間で)相対的に評価することが好ましい。
【0100】
続いて、図2を参照して、第1〜第5実施形態のいずれも適用可能な情報処理装置のハードウェア構成の例を説明する。図1の上記の情報処理装置100は、具体的には図2の情報処理装置200により実現されてもよい。同様に、後述の図3の情報処理装置300も、具体的には図2の情報処理装置200により実現されてもよい。もちろん、図2の情報処理装置200とは異なるハードウェア構成の情報処理装置が利用されてもよい。
【0101】
図2の情報処理装置200は、電池201で駆動される携帯型の装置である。電池201は、1次電池でもよいし、充電可能な2次電池でもよい。情報処理装置200の具体例としては、例えば、ノート型PC、タブレット端末、PDA、スマートフォン、携帯電話、携帯型メディアプレーヤ、その他の各種携帯端末などが挙げられる。
【0102】
情報処理装置200は、直接的にバス・インタコネクト(bus interconnect)202に接続されたいくつかのハードウェア要素を含む。情報処理装置200は、適宜のインタフェイス回路(以下「I/F」と略す)を介して間接的にバス・インタコネクト202に接続されたいくつかのハードウェア要素も含む。
【0103】
具体的には、電池201は電池I/F203を介してバス・インタコネクト202に接続されている。電池I/F203は、電池201の物理残量値を取得するための要求を受け付けて物理残量値を返す。また、電池I/F203は、電池201から他のコンポーネントへの電力供給のオン/オフ制御に関するコマンドを受け付け、コマンドにしたがって電力供給を制御する。なお、図2では、電池201から他のコンポーネントへの電力供給路は省略されている。
【0104】
情報処理装置200はさらに、バス・インタコネクト202に接続されたCPU204とGPU(Graphics Processing Unit)205を有する。図2には1個のCPU204のみが示されているが、情報処理装置200は2個以上のCPU204を含んでもよい。また、CPU204はシングルコアCPUでもマルチコアCPUでもよい。
【0105】
同様に、情報処理装置200は2個以上のGPU205を含んでいてもよい。また、GPU205はシングルコアGPUでもマルチコアGPUでもよい。実施形態によっては、独立したGPU205はなくてもよく、代わりに、GPU205がCPU204内に統合されていてもよい。
【0106】
また、情報処理装置200はさらにタッチパネル206を有している。タッチパネル206は、出力装置(つまりディスプレイ)でもあり、入力装置(つまりポインティングデバイス)でもある。
【0107】
図2の例では、タッチパネル206は、LCD(Liquid Crystal Display)I/F207とタッチパネルI/F208を介して、バス・インタコネクト202に接続されている。LCD I/F207は、CPU204またはGPU205からの制御信号にしたがってタッチパネル206への出力を制御するためのインタフェイス回路である。タッチパネルI/F208は、タッチパネル206からの入力をCPU204に通知するためのインタフェイス回路である。
【0108】
情報処理装置200はさらにカメラ209を有し、カメラ209はカメラI/F210を介してバス・インタコネクト202に接続されている。
【0109】
情報処理装置200はさらに、バス・インタコネクト202に接続されたメモリ211と不揮発性記憶装置212を有する。メモリ211は、例えばDRAM(Dynamic Random Access Memory)でもよい。不揮発性記憶装置212は、例えば、フラッシュSSD(Solid-State Drive)でもよいし、HDD(Hard Disk Drive)でもよい。メモリ211は、メモリコントローラを介してバス・インタコネクト202に接続されていてもよい。また、不揮発性記憶装置212は、ディスクコントローラ等の制御回路を内蔵している。
【0110】
情報処理装置200はさらにRF(Radio Frequency)回路213を有し、RF回路213は無線(radio)I/F214を介してバス・インタコネクト202に接続されている。RF回路213は、例えば、3GPP(Third Generation Partnership Project)、LTE(Long Term Evolution)、WiMAX(Worldwide Interoperability for Microwave Access)などの通信規格にしたがった通信回路であってもよい(WiMAXは登録商標)。RF回路213は、アンテナ、変調器、復調器などの回路を含む。
【0111】
例えば、CPU204が生成したデータまたはメモリ211に格納されているデータは、無線I/F214を介してRF回路213に出力され、RF回路213から送信されてもよい。RF回路213が電波信号を受信すると、電波信号により表されるディジタルデータが、無線I/F214とバス・インタコネクト202を介して、他のコンポーネント(例えばCPU204またはメモリ211)に出力される。
【0112】
また、バス・インタコネクト202には、USB(Universal Serial Bus)コントローラ215が接続されている。情報処理装置200は、不図示のUSBポートを有しており、USBポートとUSBコントローラ215はUSB規格のバスで接続されている。したがって、USBポートに他のUSB対応デバイス(例えばメモリカード)が接続されると、USBコントローラ215を介して情報処理装置200とUSB対応デバイスとの間でデータ転送が可能となる。
【0113】
情報処理装置200はさらに、バス・インタコネクト202に接続されたWiFiモジュール216を有する(「WiFi」は登録商標)。なお、図2にはWiFiモジュール216の1つのブロックのみが図示されているが、WiFiモジュール216は、RF回路213と無線I/F214のように、2つのコンポーネントを含んでいてもよい。
【0114】
例えば、CPU204が生成したデータまたはメモリ211に格納されているデータは、適宜のフレーム形式にて、WiFiモジュール216から送信されてもよい。そして、WiFiモジュール216がフレームを受信すると、フレームのデータは、例えばCPU204またはメモリ211に出力される。
【0115】
情報処理装置200はさらにNFC(Near Field Communication)用のRF回路217を有する。RF回路217は、NFC I/F218を介してバス・インタコネクト202に接続されている。RF回路217は、アンテナ、変調器、復調器などの回路を含む。
【0116】
例えば、CPU204が生成したデータまたはメモリ211に格納されているデータは、NFC I/F218を介してRF回路217に出力され、RF回路217から送信されてもよい。また、RF回路217が電波信号を受信すると、電波信号により表されるディジタルデータが、NFC I/F218とバス・インタコネクト202を介して、他のコンポーネント(例えばCPU204またはメモリ211)に出力される。
【0117】
実施形態に応じて、図2の情報処理装置200とは異なるハードウェア構成の情報処理装置が利用されてもよい。例えば、入力装置として、タッチパネル206の代わりに(あるいはタッチパネル206に加えて)、マウス、キーボード、マイク、またはその組み合わせが使われてもよい。また、出力装置として、タッチパネル206の代わりに、タッチセンサ機能のない通常のディスプレイが使われてもよい。出力装置として、さらにスピーカが使われてもよい。
【0118】
また、カメラ209は省略されてもよい。USBコントローラ215やUSBバスも、省略されてもよい。
【0119】
情報処理装置200の種類によっては、RF回路213と無線I/F214が省略されてもよい。あるいは、WiFiモジュール216が省略されてもよい。あるいは、RF回路217とNFC I/F218が省略されてもよい。逆に、情報処理装置200が、バス・インタコネクト202に接続された有線LAN(Local Area Network)モジュールをさらに備えていてもよい。
【0120】
なお、図1の情報処理装置100は、具体的には図2の情報処理装置200であってもよい。その場合、以下の(12a)〜(12f)のような種々のプログラムは、不揮発性記憶装置212に予め格納されており、メモリ211にロードされ、CPU204により実行される。CPU204は、メモリ211をワーキングエリアとしても利用する。
【0121】
(12a)アプリケーションプログラム。
(12b)OS102aのプログラム。
(12c)OS102bのプログラム。
(12d)デバイスドライバのプログラム。
(12e)ハイパーバイザのプログラム(例えばファームウェアプログラムであってもよい)。
(12f)図1の評価部103、通知部104、第1の取得部105、および第2の取得部106としてCPU204を機能(serve)させるための所定のプログラム。
【0122】
なお、(12f)の「所定のプログラム」は、例えば、(12d)のデバイスドライバのプログラムの一部であってもよいし、(12e)のハイパーバイザのプログラムの一部であってもよい。
【0123】
CPU204は、(12f)の所定のプログラムをメモリ211にロードして(12f)の所定のプログラムを実行する。CPU204は、(12f)の所定のプログラムを実行することにより、評価部103、通知部104、第1の取得部105、および第2の取得部106として機能する。
【0124】
なお、(12f)の所定のプログラムは、情報処理装置200にプレインストールされていてもよく、ネットワークからダウンロードされてもよく、記憶媒体からコピーされてもよい。ダウンロードは、具体的には、RF回路213と無線I/F214を介して行われてもよいし、あるいは、WiFiモジュール216を介して行われてもよい。記憶媒体は、例えばUSBメモリスティックであってもよい。
【0125】
実施形態によっては、情報処理装置200が光ディスクドライブを有していてもよい。その場合、上記所定のプログラムを記憶する記憶媒体は、光ディスクであってもよい。光ディスクの例は、CD(Compact Disc)やDVD(Digital Versatile Disk)などである。
【0126】
もちろん、磁気ディスクや光磁気ディスクなどの、その他の種類の記憶媒体が使われてもよい。記憶媒体の種類に応じて、情報処理装置200が適宜のドライブ装置を備えていてもよいし、情報処理装置200がUSBポートを介して適宜のドライブ装置と接続されてもよい。
【0127】
なお、以上の図2の説明において、メモリ211、不揮発性記憶装置212、各種記憶媒体について述べたが、これらはすべて、コンピュータ読み取り可能な有形の(tangible)媒体である。これらの有形の媒体は、信号搬送波のような一時的な(transitory)媒体ではない。
【0128】
ところで、第1の取得部105が取得する特性情報が、優先度情報などの静的な情報を含む場合、静的な特性情報は、図2の不揮発性記憶装置212に予め格納されていてもよい。そして、第1の取得部105として機能するCPU204が、不揮発性記憶装置212から静的な特性情報を取得してもよい。あるいは、第1の取得部105として機能するCPU204は、OS102aと102bの動作を監視することにより、動的な特性情報を生成し、生成によって特性情報を取得してもよい。
【0129】
第2の取得部106として機能するCPU204は、具体的には、電池201の物理残量値を取得するための要求を、バス・インタコネクト202を介して電池I/F203に送ってもよい。すると、CPU204は、電池I/F203を介して物理残量値を取得する。
【0130】
続いて、図3〜9を参照して、第2実施形態について説明する。
図3は、第2実施形態の情報処理装置のブロック構成図である。以下に述べるとおり、図3の情報処理装置300は仮想化されている。
【0131】
情報処理装置300は、様々な種類のハードウェア310を有する。ハードウェア310の1つは電池311である。また、情報処理装置300は図2の情報処理装置200により実現されてもよい。つまり、ハードウェア310が、CPU204、GPU205、タッチパネル206、カメラ209、メモリ211、不揮発性記憶装置212、RF回路213、USBコントローラ215、WiFiモジュール216、およびRF回路217などを含んでいてもよい。
【0132】
ハードウェア310上ではハイパーバイザ320が動作する。ハイパーバイザ320は「仮想マシンモニタ」とも呼ばれる。
【0133】
ハイパーバイザ320上では、複数の種類のハードウェア310にそれぞれ対応する仮想ドライバ(virtual drivers)330が動作する。仮想ドライバ330のうちの1つは、電池311に対応する仮想電池ドライバ340である。
【0134】
また、情報処理装置300には複数の仮想マシンが構築されている。ハイパーバイザ320上で動作する仮想マシンは、「ドメイン」、「論理ドメイン」、「パーティション」などとも呼ばれる。図3の例では、2つの仮想マシン350aと350bがハイパーバイザ320上で動作する。
【0135】
仮想マシン350a内ではOS351aが動作し、OS351a上で1つ以上のアプリケーション352aが動作する。同様に、仮想マシン350b内では、OS351bが動作し、OS351b上で1つ以上のアプリケーション352bが動作する。
【0136】
情報処理装置300が情報処理装置200により実現される場合、以下の(13a)〜(13d)の各種のプログラムが図2のCPU204により実行される。
【0137】
(13a)ハイパーバイザ320のプログラム(上記(12e)のプログラムに対応する)。
(13b)仮想電池ドライバ340を含む仮想ドライバ330それぞれのプログラム(上記(12f)のプログラムを含む(12d)のプログラム、およびその他の(12d)のプログラムに対応する)。
(13c)OS351aと351bのプログラム(上記(12b)と(12c)のプログラムに対応する)。
(13d)アプリケーション352aと352bのプログラム(上記(12a)のプログラムに対応する)。
【0138】
上記(13a)〜(13d)のプログラムは、不揮発性記憶装置212に予め格納されていてもよい。あるいは、上記(13a)〜(13d)のプログラムは、RF回路213と無線I/F214を介してネットワークからダウンロードされてもよいし、WiFiモジュール216を介してネットワークからダウンロードされてもよい。上記(13a)〜(13d)のプログラムは、コンピュータ読み取り可能な記憶媒体から読み取られて、不揮発性記憶装置212にコピーされてもよい。いずれにしろ、上記(13a)〜(13d)のプログラムは、メモリ211にロードされて、CPU204により実行される。
【0139】
仮想電池ドライバ340は、プロファイラ341aと341bを含む。プロファイラ341aは、OS351aに対応する(換言すれば、仮想マシン350aに対応する)。プロファイラ341bは、OS351bに対応する(換言すれば、仮想マシン350bに対応する)。仮想電池ドライバ340はさらに、取得部342と計算部343も含む。
【0140】
プロファイラ341aと341bは、図1の第1の取得部105と類似しており、特性情報の一部(より具体的には使用状況情報)を取得する。また、プロファイラ341aと341bは、図1の通知部104とも類似している。つまり、プロファイラ341aと341bは、OS351aと351bにそれぞれ仮想残量値を通知する。
【0141】
取得部342は、図1の第2の取得部106と類似しており、電池311の物理残量値を取得する。計算部343は、評価部103と類似している。具体的には、計算部343は、特性情報と物理残量値から仮想残量値を計算し、計算した仮想残量値をプロファイラ341aと341bに出力する。
【0142】
仮想電池ドライバ340内の上記のコンポーネントのさらなる詳細は、図6〜7のフローチャートとともに後述する。
【0143】
図3には、計算部343が仮想残量値の計算に用いる様々な情報も図示されている。具体的には、使用状況情報344、優先度情報345、モード情報346、およびフラグ347が、図3に示されている。これら各種の情報の詳細は、図4、6、および7とともに後述する。
【0144】
続いて、図4を参照して、図3の使用状況情報344、優先度情報345、およびモード情報346の具体例について説明する。図4は、第2実施形態で使われるプロファイルの例を示す図である。
【0145】
図4のプロファイル401aは、OS351aに対応する使用状況情報344、優先度情報345、およびモード情報346を含む。同様に、プロファイル401bは、OS351bに対応する使用状況情報344、優先度情報345、およびモード情報346を含む。プロファイル401aと401bは、物理的なメモリ211上の、仮想電池ドライバ340が使用する領域内に、格納されている。
【0146】
プロファイル401a中の優先度情報345によれば、OS351aの優先度は「5」である。プロファイル401a中のモード情報346によれば、OS351aのモードは「第3モード」である。
【0147】
他方、プロファイル401b中の優先度情報345によれば、OS351bの優先度は「2」である。プロファイル401b中のモード情報346によれば、OS351bのモードは「第1モード」である。
【0148】
モードの詳細は図6〜7とともに後述するが、モード情報346により表されるモードは、電池311が充電中の場合に計算部343が仮想残量値を評価する方法を示す。第2実施形態では、「第1モード」から「第3モード」までの3種類のモードが定義されているものとする。
【0149】
優先度情報345とモード情報346は、予め決められた静的な情報である。例えば、優先度情報345とモード情報346は、ユーザからの入力に応じて設定されてもよい。例えば、優先度情報345とモード情報346は、不揮発性記憶装置212に予め格納されていてもよく、仮想電池ドライバ340により不揮発性記憶装置212から読み出されてメモリ211上にロードされてもよい。
【0150】
プロファイル401a中の使用状況情報344は、具体的には、T個の期間(T≧1)のそれぞれにおいて、OS351aおよびアプリケーション352aの動作に起因して使用された物理資源の量を、物理資源ごとに示す。同様に、プロファイル401b中の使用状況情報344は、T個の期間のそれぞれにおいて、OS351bおよびアプリケーション352bの動作に起因して使用された物理資源の量を、物理資源ごとに示す。図示の便宜上、図4において使用状況情報344はテーブル形式で示されている。
【0151】
使用状況情報344のテーブルの各行は、1つの期間に対応する。期間の長さは予め決められた定数である。
【0152】
使用状況情報344のテーブルの各列は、1つの物理資源(具体的には物理デバイス)についての1つの観測項目に対応する。図4は、「CPU204(またはCPU204内のコア)については、使用率と周波数という2つの項目が観測されるが、GPU205やWiFiモジュール216については1つの項目しか観測されない」という場合の使用状況情報344の例を示す。
【0153】
紙幅の都合上、図4では一部の物理デバイスに対応する使用状況情報344のみが例示されており、他の物理デバイスに対応する使用状況情報344は省略されている。プロファイル401b中の使用状況情報344も、プロファイル401a中の使用状況情報344と同様に、テーブル形式で図示されている。
【0154】
なお、物理デバイスと仮想デバイスの間の対応関係は、実施形態に応じて様々である。対応関係に応じて、使用状況情報344のテーブルの列の数は異なり得る。
【0155】
例えば、図2に関して説明したように、物理CPUは1台でも複数台でもよく、各物理CPUは、シングルコアCPUでもマルチコアCPUでもよい。また、各仮想マシンの仮想CPUの数も任意である。ハイパーバイザ320は、各仮想マシンに対して、シングルコアの仮想CPUを提供してもよいし、マルチコアの仮想CPUを提供してもよい。
【0156】
よって、物理CPUと仮想CPUの間の対応関係は、実施形態に応じて様々である。具体例をいくつか挙げると、例えば以下の(14a)〜(14f)のような場合があり得る。もちろん、さらに別の場合もあり得る。なお、下記(14e)の場合は、(14a)の場合のより具体的な例である、とも見なせる。
【0157】
(14a)シングルコアまたはマルチコアの物理CPUが1台ある。当該物理CPUは、仮想マシン350aの仮想CPUに割り当てられるとともに、仮想マシン350bの仮想CPUにも割り当てられる。つまり、仮想マシン350aと350bは同じ物理CPUを共有する。
(14b)シングルコアまたはマルチコアの物理CPUが2台ある。第1物理CPUは、仮想マシン350aの仮想CPUに割り当てられる。第2物理CPUは、仮想マシン350bの仮想CPUに割り当てられる。
(14c)シングルコアまたはマルチコアの物理CPUが3台ある。第1物理CPUと第2物理CPUは、仮想マシン350aの仮想CPUに割り当てられる。ハイパーバイザ320は、シングルコアのCPUが1台だけが存在するかのように仮想マシン350aに認識させてもよいし、デュアルコアの(dual-core)CPUが1台だけ存在するかのように仮想マシン350aに認識させてもよい。後者の場合、例えば第1物理CPUが仮想CPUの第1コアに割り当てられ、第2物理CPUが仮想CPUの第2コアに割り当てられてもよい。また、第3物理CPUは、仮想マシン350bの仮想CPUに割り当てられる。
(14d)デュアルコアの物理CPUが1台ある。当該物理CPUの第1コアは、仮想マシン350aの仮想CPUに割り当てられ、仮想マシン350aからは1台のCPUとして認識される。当該物理CPUの第2コアは、仮想マシン350bの仮想CPUに割り当てられ、仮想マシン350bからは1台のCPUとして認識される。
(14e)デュアルコアの物理CPUが1台ある。当該物理CPUの第1コアは、仮想マシン350aの仮想CPUの第1コアに割り当てられるとともに、仮想マシン350bの仮想CPUの第1コアにも割り当てられる。また、当該物理CPUの第2コアは、仮想マシン350aの仮想CPUの第2コアに割り当てられるとともに、仮想マシン350bの仮想CPUの第2コアにも割り当てられる。
(14f)クアッドコアの(quad-core)物理CPUが1台ある。当該物理CPUの第1コアと第2コアは、仮想マシン350aの仮想CPUの第1コアと第2コアにそれぞれ割り当てられる。つまり、仮想マシン350aからは、デュアルコアの1台のCPUが存在するかのよう認識される。また、当該物理CPUの第3コアと第4コアは、仮想マシン350bの仮想CPUの第1コアと第2コアにそれぞれ割り当てられる。つまり、仮想マシン350bからは、デュアルコアの1台のCPUが存在するかのよう認識される。
【0158】
以上のように、物理デバイスと仮想デバイスの間の対応関係は、実施形態に応じて様々であり、対応関係に応じて、使用状況情報344のテーブルの列の数は異なり得る。例えば、上記(14a)〜(14f)の場合、使用状況情報344のテーブルにおける、CPU(またはCPUコア)に関する列の数は、以下のとおりである。
【0159】
上記(14a)の場合、プロファイル401aの使用状況情報344のテーブルには、1台の物理CPUの使用率と周波数にそれぞれ対応する2つの列がある。同様に、プロファイル401bの使用状況情報344のテーブルにも、1台の物理CPUの使用率と周波数にそれぞれ対応する2つの列がある。
【0160】
上記(14b)の場合、プロファイル401aの使用状況情報344のテーブルには、第1物理CPUの使用率と周波数にそれぞれ対応する2つの列がある。他方、プロファイル401bの使用状況情報344のテーブルには、第2物理CPUの使用率と周波数にそれぞれ対応する2つの列がある。
【0161】
上記(14c)の場合、プロファイル401aの使用状況情報344のテーブルには、第1物理CPUの使用率と周波数にそれぞれ対応する2つの列と、第2物理CPUの使用率と周波数にそれぞれ対応する2つの列がある。他方、プロファイル401bの使用状況情報344のテーブルには、第3物理CPUの使用率と周波数にそれぞれ対応する2つの列がある。
【0162】
上記(14d)の場合、プロファイル401aの使用状況情報344のテーブルには、物理CPUの第1コアの使用率と周波数にそれぞれ対応する2つの列がある。他方、プロファイル401bの使用状況情報344のテーブルには、物理CPUの第2コアの使用率と周波数にそれぞれ対応する2つの列がある。
【0163】
上記(14e)の場合、プロファイル401aの使用状況情報344のテーブルには、物理CPUの第1コアの使用率と周波数にそれぞれ対応する2つの列と、物理CPUの第2コアの使用率と周波数にそれぞれ対応する2つの列がある。同様に、プロファイル401bの344のテーブルにも、物理CPUの第1コアの使用率と周波数にそれぞれ対応する2つの列と、物理CPUの第2コアの使用率と周波数にそれぞれ対応する2つの列がある。
【0164】
上記(14f)の場合、プロファイル401aの使用状況情報344のテーブルには、物理CPUの第1コアの使用率と周波数にそれぞれ対応する2つの列と、物理CPUの第2コアの使用率と周波数にそれぞれ対応する2つの列がある。他方、プロファイル401bの使用状況情報344のテーブルには、物理CPUの第3コアの使用率と周波数にそれぞれ対応する2つの列と、物理CPUの第4コアの使用率と周波数にそれぞれ対応する2つの列がある。
【0165】
したがって、例えば(14a)、(14b)または(14d)の場合には、図4に示すように、プロファイル401aと401bのどちらの使用状況情報344のテーブルにも、CPU(またはCPUコア)に関して、使用率と周波数の列が1つずつある。
【0166】
例えば、プロファイル401a中の使用状況情報344は、以下の(15a)〜(15d)のことを示す。
【0167】
(15a)OS351aおよびアプリケーション352aによるCPU使用率は、直近の期間においては50%であり、直近から2番目の期間においては20%であり、直近からT番目の期間においては60%である。なお、ここでの「CPU使用率」は、仮想マシン350aの仮想CPUに割り当てられている物理CPU(または物理CPUコア)の使用率である。
(15b)仮想マシン350aの仮想CPUに割り当てられている物理CPU(または物理CPUコア)のクロック周波数は、直近の期間においては500MHzであり、直近から2番目の期間と直近からT番目の期間においては1GHzである。
(15c)OS351aとアプリケーション352aの少なくとも一方が、仮想マシン350aの仮想GPUを、直近の期間と直近からT番目の期間において使用した。つまり、仮想マシン350aの仮想GPUに割り当てられている物理GPU(具体的にはGPU205)は、OS351aまたはアプリケーション352aの動作に起因して、直近の期間と、直近からT番目の期間において使用された。しかし、直近から2番目の期間においては、OS351aまたはアプリケーション352aの動作に起因して上記物理GPUが使用されることはなかった。
(15d)OS351aとアプリケーション352aが直近の期間において、仮想WiFiデバイスを介して受信したデータの量と仮想WiFiデバイスを介して送信したデータの量の総和は10kBである。つまり、仮想マシン350aの仮想WiFiデバイスに割り当てられた物理WiFiデバイス(具体的にはWiFiモジュール216)を介して、OS351aまたはアプリケーション352aに関して行われた通信のデータ量は、直近の期間では10kBである。また、当該データ量は、直近から2番目の期間においては25kBであり、直近からT番目の期間においては35kBである。
【0168】
なお、OS351aは、仮想マシン350aの仮想CPUに割り当てられている物理CPU(または物理CPUコア)のクロック周波数を変更するためのハイパーバイザコールを発行してもよい。ただし、実際に物理CPU(または物理CPUコア)のクロック周波数を変更するか否かは、ハイパーバイザ320が決定する。例えば、1つの物理CPU(または1つの物理CPUコア)が複数の仮想マシンにより共有されている場合、ハイパーバイザ320は、クロック周波数を変更しないことに決定してもよい。
【0169】
ハイパーバイザ320は、クロック周波数を変更することに決定した場合、決定にしたがって、物理CPU(または物理CPUコア)に対して、クロック周波数を変更するための命令を発行する。本実施形態では、以上のようにクロック周波数が可変であるため、上記(15b)のようにクロック周波数が使用状況情報344として記録される。
【0170】
また、図4では、物理GPUが期間中に使用されたことを「ON」と表し、物理GPUが期間中に使用されなかったことを「OFF」と表している。
【0171】
なお、プロファイル401b中の使用状況情報344は、プロファイル401a中の使用状況情報344と同様の形式なので、詳しい説明を省略する。
【0172】
さて、以上説明したようなプロファイル401a中の使用状況情報344は、プロファイラ341aにより生成され、記録される。例えば、プロファイラ341aは、OS351aの動作を監視することにより、プロファイル401a中の使用状況情報344を生成してもよい。そして、プロファイラ341aは、生成した使用状況情報344を例えばメモリ211に格納してもよい。以上のように、プロファイラ341aは監視と生成により、使用状況情報344を取得してもよい。
【0173】
同様に、プロファイラ341bはOS351bの動作を監視することにより、プロファイル401b中の使用状況情報344を生成してもよい。そして、プロファイラ341bは、生成した使用状況情報344を例えばメモリ211に格納してもよい。
【0174】
より具体的には、プロファイラ341aは、例えば、ハイパーバイザ320への問い合わせを介して、仮想マシン350aの動作に起因する物理CPU使用率を取得してもよい。つまり、プロファイラ341aは、物理CPU時間のうち、OS351aとアプリケーション352aにより消費された時間の割合を、ハイパーバイザ320への問い合わせを介して、物理CPUごとに(あるいは物理CPUコアごとに)取得してもよい。
【0175】
ところで、アプリケーション352aがデバイスを利用する場合、アプリケーション352aはシステムコールを呼び出してもよい。そして、システムコールに応じて、OS351aが、アプリケーション352aの利用しようとするデバイスに対応する仮想ドライバ330に対して、命令を発行してもよい。仮想ドライバ330は、OS351aからの命令に応じて、ハイパーバイザコールを呼び出すことで、物理デバイスにアクセスしてもよい。
【0176】
つまり、アプリケーション352aがOS351aを介してデバイスを利用する場合に、OS351aからの命令に応じて仮想ドライバ330がハイパーバイザコールを呼び出すことがある。もちろん、OS351aがアプリケーション352aとは無関係にデバイスを利用する場合に、OS351aからの命令に応じて仮想ドライバ330がハイパーバイザコールを呼び出すこともあり得る。したがって、プロファイラ341aは、OS351aからの命令に応じて仮想ドライバ330から呼び出されたハイパーバイザコールを集計する(aggregate)ことで、上記のような物理デバイスごとの使用状況情報344を生成してもよい。
【0177】
実施形態に応じてハイパーバイザコールの具体的な形式は異なり得るが、プロファイラ341aは、ハイパーバイザコールの形式に応じて、適宜、プロファイル401a中の使用状況情報344を生成する。例えば、プロファイラ341aは、ハイパーバイザコールの種類ごと、ハイパーバイザコールの引数の値ごと、あるいは、種類と引数の値の組み合わせごとに、ハイパーバイザコールの回数をカウントしてもよい。
【0178】
また、或る種のハイパーバイザコールが数値的な引数をとる場合、プロファイラ341aは、当該或る種のハイパーバイザコールに関して、引数の和を計算してもよい。プロファイラ341aは、このような計算によって、数値的な使用状況情報344を取得してもよい。例えば、上記(15d)のデータ量は、数値的な使用状況情報344の例である。
【0179】
あるいは、ハイパーバイザ320のアーキテクチャによっては、特定の仮想マシンのデバイスドライバが、ハードウェア310へのアクセスを提供してもよい。図3では便宜上、仮想ドライバ330が仮想マシン350aと350bの外側に描かれているが、例えば仮想マシン350aが上記「特定の仮想マシン」である場合、仮想マシン350aのデバイスドライバが、ハードウェア310へのアクセスを提供してもよい。
【0180】
この場合、仮想マシン350a内には、他の仮想マシン350b内のデバイスドライバ(すなわちフロントエンドドライバ)との間のインタフェイスとして機能するバックエンドドライバと、実際にハードウェア310にアクセスする実ドライバがあってもよい。仮想マシン350b内のフロントエンドドライバは、ハイパーバイザ320を介して仮想マシン350a内のバックエンドドライバに対してアクセス要求を発行するためのインタフェイスである。
【0181】
例えば、或る種の物理デバイスに関して、プロファイラ341bは、仮想マシン350b内のフロントエンドドライバから仮想マシン350a内のバックエンドドライバへの要求を監視してもよい。そして、プロファイラ341bは、要求の回数をカウントすることにより(または、要求の種類もしくは引数に応じて適宜の集計処理を行うことにより)、仮想マシン350bに対応する使用状況情報344を取得してもよい。
【0182】
プロファイラ341aは、仮想マシン350a内のOS351aまたはアプリケーション352aの動作に起因するハードウェア310へのアクセスを監視してもよい。具体的には、プロファイラ341aは、仮想マシン350b内のフロントエンドドライバからの要求とは関係なく実ドライバが行うハードウェア310へのアクセスを監視してもよい。そして、プロファイラ341aは、アクセスの回数をカウントすることにより(または、アクセスの種類もしくは引数に応じて適宜の集計処理を行うことにより)、仮想マシン350aに対応する使用状況情報344を取得してもよい。
【0183】
なお、仮想電池ドライバ340は、電池311に関するバックエンドドライバと実ドライバの組み合わせにより実現されていてもよい。例えば、物理残量値を取得する取得部342は、実ドライバ内にあってもよい。プロファイラ341aと341bは、バックエンドドライバ内にあってもよい。図3ではプロファイラ341bとOS351bが線でつながれているが、電池311に対応するバックエンドドライバ内にプロファイラ341bがある場合、プロファイラ341bは、仮想マシン350b内で電池311に対応するフロントエンドドライバを介して、OS351bに仮想残量値を通知してもよい。
【0184】
実施形態によっては、ハイパーバイザ320が、問い合わせに応じて、物理デバイスとOSの組み合わせごとに(または物理デバイスと仮想マシンの組み合わせごとに)、使用状況情報344を応答する機能を提供していてもよい。その場合、プロファイラ341aは、ハイパーバイザ320への問い合わせを介して、プロファイル401a内の使用状況情報344を取得してもよい。同様に、プロファイラ341bも、ハイパーバイザ320への問い合わせを介して、プロファイル401b内の使用状況情報344を取得してもよい。
【0185】
なお、図4の例から理解されるとおり、使用状況情報344がどのような形式で表されるかは、物理デバイスごとに異なり得る。
【0186】
例えば、CPU204(またはCPU204のコア)の使用状況情報344は、パーセンテージと周波数で表される。実施形態によっては、GPU205(またはGPU205のコア)の使用状況情報344も、パーセンテージと周波数で表されてもよい。しかし、図4の例では、GPU205の使用状況情報344は、2値的に「ON」と「OFF」で表される。また、WiFiモジュール216の使用状況情報344は、データ量(図4の例ではキロバイト単位の量)により数値的に表される。
【0187】
タッチパネル206からの入力に関する使用状況情報344も、2値的に表されてもよい。例えば、OS351aまたはアプリケーション352aに対応する表示領域内に、期間中にユーザが1回でも触った場合は、プロファイル401aにおいて、タッチパネル206からの入力に関する使用状況情報344の値は、「ON」である。逆に、期間中にユーザが上記表示エリア内に触らなかった場合、使用状況情報344の値は、「OFF」である。
【0188】
実施形態によっては、タッチパネル206からの入力に関する使用状況情報344が、数値的に表されてもよい。例えば、タッチパネル206からタッチパネルI/F208を介してバス・インタコネクト202に出力されたデータの量が、数値的な使用状況情報344として利用可能である。プロファイラ341aは、当該データ量を、タッチパネル206からの入力に対応する仮想ドライバ330がOS351aに対して発行する割り込みの回数、または、そのような割り込みの引数に基づいて、計算してもよい。
【0189】
また、タッチパネル206への出力に関する使用状況情報344も、数値的に表されてもよい。具体的には、期間中にVRAM(Video Random Access Memory)へ出力されたデータ量により、タッチパネル206への出力に関する使用状況情報344が表されてもよい。例えば、プロファイラ341aは、当該データ量を、タッチパネル206への出力に対応する仮想ドライバ330がOS351aからの命令に応じて発行するハイパーバイザコールの引数に基づいて、計算してもよい。
【0190】
USBコントローラ215に関する使用状況情報344も同様に、2値的に表されてもよいし、数値的に表されてもよい。つまり、使用状況情報344は、USBコントローラ215を介してUSBデバイスが使用されたか否かを示してもよいし、USBコントローラ215を介して転送されたデータの量を示してもよい。
【0191】
カメラ209に関する使用状況情報344は、例えば、カメラ209により撮像された画像のデータ量により、数値的に表されてもよい。情報処理装置200がスピーカを有する場合、スピーカに関する使用状況情報344は、スピーカに出力されたオーディオデータの量により、数値的に表されてもよい。実施形態によっては、カメラ209やスピーカに関する使用状況情報344が2値的に表されてもよい。
【0192】
RF回路213の使用状況情報344も、WiFiモジュール216の使用状況情報344と同様に、RF回路213によって通信されたデータの量により、数値的に表されてもよい。同様に、RF回路217の使用状況情報344も、数値的に表されてもよい。
【0193】
なお、デバイスの種類によっては、使用状況情報344が、数値的でも2値的でもなく、n値的(n-ary)に表されてもよい(n>2)。
【0194】
以上のとおり、使用状況情報344の形式は様々である。しかし、使用状況情報344の形式によらず、プロファイラ341aは、物理デバイスの種類に応じた適宜の監視または問い合わせにより、プロファイル401aの使用状況情報344を取得することができる。同様に、プロファイラ341bも、使用状況情報344の形式によらず、プロファイル401bの使用状況情報344を取得することができる。
【0195】
例えば、上記のように物理CPU(または物理CPUコア)のクロック周波数が実際に変更されるか否かは、ハイパーバイザ320が決定する。よって、クロック周波数の変更を要求するハイパーバイザコールをOS351aが発行したら、プロファイラ341aは、ハイパーバイザ320に実際のクロック周波数を問い合わせてもよい。
【0196】
ところで、OS351aと351bは、互いに独立に、電源管理に関する各々のポリシにしたがって動作する。第2実施形態では、電源管理に関するポリシは、具体的には、複数のルールを含むルールセットにより表される。図5は、第2実施形態で使われるルールセットの例を示す図である。
【0197】
図5の例では、OS351aには2つのルールセット500と520が予め定義されており、OS351bには1つのルールセット540が予め定義されている。複数のルールセットが定義されているOSでは、それら複数のルールセットのうち1つが選択可能である。例えば、ユーザからの入力に応じて、OS351aではルールセット500が選択されていてもよい。
【0198】
各ルールセットは複数のルールを含む。各ルールは、OSが認識する電池311の残量値(すなわち仮想残量値)に関する条件と対応づけられている。条件とルールの間の対応づけは、「当該条件が成立する場合に、OSが当該ルールを適用する」ということを表す。
【0199】
例えば、ルールセット500では3つの条件501〜503が定義されており、ルールセット500は7つのルール504〜510を含む。ルール504〜510の各々は、条件501〜503のいずれかに対応づけられている。以下では説明の便宜上、電池の残量は、Wh単位で表される(すなわち、使用可能な残りの電力量により表される)ものとする。
【0200】
条件501は、「電池311の残量としてOS351aが認識する値(すなわちOS351aに通知された仮想残量値)が、20Wh以上である」という条件である。条件502は、「電池311の残量としてOS351aが認識する値が、5Wh以上20Wh未満である」という条件である。条件503は、「電池311の残量としてOS351aが認識する値が、5Wh未満である」という条件である。
【0201】
ところで、以下では説明の便宜上、ハイパーバイザ320による仮想化の結果としてOS351aが認識するCPU(つまり仮想CPU)のコアの数が2であるものとする。同様に、OS351bが認識するCPUのコアの数も2であるものとする。例えば、上記(14e)と(14f)の場合は、いずれも、OS351aが認識する仮想CPUのコアの数が2であり、かつ、OS351bが認識する仮想CPUのコアの数も2である。
【0202】
さて、ルールセット500において、ルール504は、条件501に対応づけられている。ルール504は、「OS351aが認識する2つの仮想CPUコアのうち、第1コアを1GHzで動作させる」というルールである。
【0203】
ルール505も条件501に対応づけられている。ルール505は、「OS351aが認識する2つの仮想CPUコアのうち、第2コアを500MHzで動作させる」というルールである。
【0204】
OS351aに20Wh以上の仮想残量値が通知された場合、OS351aは、ルール504と505を適用する。具体的には、OS351aは、仮想CPUの第1コアを1GHzで動作させるための命令を発行し、仮想CPUの第2コアを500MHzで動作させるための命令を発行する。これらの命令は、具体的にはハイパーバイザコールであってもよい。
【0205】
ハイパーバイザ320は、OS351aからのハイパーバイザコールにしたがって、物理CPUコアのクロック周波数を変更してもよいし、変更しなくてもよい。例えば、ハイパーバイザ320は、OS351aからのハイパーバイザコールにしたがって、物理CPU時間のOS351aへの割り当てを調整してもよく、物理CPUコアのクロック周波数自体は変更しなくてもよい。
【0206】
さて、ルール506〜509は、いずれも条件502に対応づけられている。よって、OS351aに5Wh以上20Wh未満の仮想残量値が通知された場合、OS351aは、ルール506〜509を適用する。
【0207】
ルール506は、「第1コアを500MHzで動作させる」というルールである。ルール507は、「第2コアを100MHzで動作させる」というルールである。ルール508は、「WiFiモジュールを介した通信のデータレートを1kB/hまでに制限する」というルールである。ルール509は、「画面に警告を表示する」というルールである。
【0208】
また、条件503にはルール510が対応づけられている。ルール510は、「強制的にスリープする」というルールである。よって、5Wh未満の仮想残量値がOS351aに通知されると、OS351aはアプリケーション352aをスリープさせ、OS351a自体もスリープする。
【0209】
さて、ルールセット520では3つの条件521〜523が定義されている。条件521は、「電池311の残量としてOS351aが認識する値(すなわちOS351aに通知された仮想残量値)が、25Wh以上である」という条件である。条件522は、「電池311の残量としてOS351aが認識する値が2.5Wh以上25Wh未満である」という条件である。条件523は、「電池311の残量としてOS351aが認識する値が、2.5Wh未満である」という条件である。
【0210】
条件521にはルール524と525が対応づけられており、条件522にはルール526〜529が対応づけられており、条件523にはルール530が対応づけられている。ルール524〜530は、それぞれ、ルール504〜510と同じである。つまり、ルールセット500と520には、同じルールが含まれるが、各ルールが適用される条件が、ルールセット500と520では異なる。
【0211】
例えば、22Whという仮想残量値がOS351aに通知された場合、もしルールセット500が選択されていれば、OS351aはルール504と505を適用する。しかし、もしルールセット520が選択されていれば、OS351aはルール526〜529を適用する。
【0212】
ところで、OS351bには1つのルールセット540が定義されており、OS351bはルールセット540にしたがって動作する。ルールセット540では3つの条件541〜543が定義されており、ルールセット540は5つのルール544〜548を含む。
【0213】
条件541は、「ドントケア(don't care)」を示す条件である。つまり、電池311の残量としてOS351bが認識する値(すなわちOS351bに通知された仮想残量値)によらず、条件541は常に「成立する」と見なされる。条件542は、「電池311の残量としてOS351bが認識する値が、30Wh未満である」という条件である。条件543は、「電池311の残量としてOS351bが認識する値が、7.5Wh未満である」という条件である。
【0214】
ルール544は条件541に対応づけられている。ルール544は、「OS351bが認識する2つの仮想CPUコアのうち、第1コアを1GHzで動作させる」というルールである。
【0215】
ルール545も条件541に対応づけられている。ルール545は、「OS351bが認識する2つの仮想CPUコアのうち、第2コアを停止する」というルールである。
ルール544を適用する場合、OS351bは、具体的には、第1コアを1GHzで動作させるためのハイパーバイザコールを呼び出してもよい。同様に、ルール545を適用する場合、OS351bは、具体的には、第2コアを停止するためのハイパーバイザコールを呼び出してもよい。
【0216】
ハイパーバイザコールに応じてハイパーバイザ320が実際に物理CPUコアのクロック周波数を変更するか否かは、場合による。同様に、ハイパーバイザコールに応じてハイパーバイザ320が実際に物理CPUコアを停止させるか否かも、場合による。
【0217】
ルール546は、条件542に対応づけられている。ルール546は、「ディスプレイのバックライトを減光する」というルールである。
【0218】
なお、OS351bは、物理デバイスであるタッチパネル206自体を認識しているのではなく、タッチパネル206に対応する仮想ディスプレイを認識している。よって、ルール546を適用する場合、OS351bは、ディスプレイのバックライトを減光するための命令を、仮想ドライバ330のうちの仮想ディスプレイドライバに対して発行してもよい。OS351bから発行された命令に応じて、実際にタッチパネル206のバックライトが減光されるか否かは、場合による。
【0219】
ルール547も、条件542に対応づけられている。ルール547は、「ネットワーク通信を行うプロセスをサスペンド状態にする」というルールである。例えば、OS351bは、どのプロセスがネットワーク通信を行うのかを判断するために、ネットワーク通信のためにユーザプロセスから呼び出されるシステムコールを監視してもよい。
【0220】
ルール548は、条件543に対応づけられている。ルール548は、「GPUを省電力モードに変更する」というルールである。ルール548を適用する場合、OS351bは、物理デバイスであるGPU205に対応する仮想GPUを省電力モードに変更するための命令を発行する。当該命令は、具体的にはハイパーバイザコールであってもよい。
【0221】
例えば、10Whという仮想残量値がOS351bに通知された場合、条件541と542の双方が成立する。よって、この場合、OS351bは、ルール544〜547を適用する。
【0222】
続いて、図3の情報処理装置300が行う処理について説明する。情報処理装置300の電源がオンになっている間、以下の(16a)〜(16c)の処理が並行に実行される。
【0223】
(16a)プロファイル401a中の使用状況情報344を取得するために、プロファイラ341aが実行する処理。例えば、図4に関して説明したように、OS351aから仮想ドライバ330を介して呼び出される(またはOS351aから直接呼び出される)ハイパーバイザコールを監視する処理など。
(16b)プロファイル401b中の使用状況情報344を取得するために、プロファイラ341bが実行する処理。
(16c)仮想電池ドライバ340により実行される図6〜7の処理。
【0224】
以下、図6〜7の処理について詳しく説明する。情報処理装置300に電源が入れられると、図6〜7の処理が開始される。図6〜7の処理フローは、仮想電池ドライバ340により制御される。
【0225】
まず、ステップS101で仮想電池ドライバ340は、適宜の初期化を行う。初期化の詳細は、実施形態に応じて様々であってよい。
【0226】
例えば、プロファイラ341aは、OS351aに対応づけられて予め不揮発性記憶装置212に記憶されている優先度情報345とモード情報346を読み出してもよい。そして、プロファイラ341aは、読み出した優先度情報345とモード情報346を、プロファイル401a用に割り当てられたメモリ211上の領域にコピーしてもよい。また、プロファイラ341aは、プロファイル401a中の使用状況情報344を格納するための、メモリ211上の領域をクリアしてもよい。プロファイラ341bも、プロファイラ341aと同様の初期化を適宜行う。
【0227】
また、計算部343が、OS351aに対応する仮想残量値の初期値と、OS351bに対応する仮想残量値の初期値を、ステップS101で計算してもよい。そして、計算された初期値をプロファイラ341aと341bがそれぞれOS351aと351bに通知してもよい。
【0228】
実施形態によっては、ステップS101での初期値の計算と通知は省略されてもよい。また、計算部343が初期値を計算する方法も、実施形態に応じて様々であってよい。例えば、取得部342が物理残量値を取得してもよい。そして、計算部343が優先度情報345と物理残量値に基づいてOS351aと351bそれぞれに対応する仮想残量値の初期値を計算してもよい。
【0229】
あるいは、OS351aと351bそれぞれに対応する仮想残量値の初期値が、予め決められていてもよい。この場合、計算部343は初期値を計算しない。プロファイラ341aは、OS351a用に予め決められた初期値をOS351aに通知し、プロファイラ341bは、OS351b用に予め決められた初期値をOS351bに通知する。
【0230】
ステップS101では、例えば以上説明したような適宜の初期化が行われる。次に、ステップS102で仮想電池ドライバ340は、所定の単位時間が経過するまで待つ。
【0231】
例えば、仮想電池ドライバ340は、タイマ割り込みを使って所定の単位時間が経過するまで待ってもよい。なお、単位時間の長さは実施形態に応じて任意である。所定の単位時間が経過すると、図6〜7の処理はステップS103へと移行する。
【0232】
ステップS103で仮想電池ドライバ340は、インデックス変数kに1を代入することで、インデックス変数kを初期化する。
【0233】
次に、ステップS104で仮想電池ドライバ340は、k番目のプロファイラに使用状況情報344の生成と記録を命令する。すると、k番目のプロファイラが、今回の期間の間のk番目のOSの動作状況から、k番目のOSについての使用状況情報344を生成し、生成した使用状況情報344を記録する。
【0234】
ここで、「今回の期間」とは、具体的には、ステップS102で経過した単位時間である。例えば単位時間が3分間である場合、「今回の期間」は、直近の3分間である。
【0235】
上記の(16a)〜(16b)のとおり、図6〜7の処理と並行して、プロファイラ341aはOS351aからデバイスへのアクセス要求を監視し、プロファイラ341bはOS351bからデバイスへのアクセス要求を監視する。つまり、ステップS102で単位時間の経過が待たれている間にも、プロファイラ341aと341bによる監視は並行して実行される。
【0236】
例えば、プロファイラ341aは、OS351aの動作状況を一時的に記憶するために、カウンタ変数やフラグ変数を用いてもよい。具体的には、プロファイラ341aは、OS351aからデバイスへのアクセス要求のたびに、例えば、アクセス要求の回数を示すためのカウンタ変数(または、アクセス要求の有無を示すためのフラグ変数)を更新してもよい。プロファイラ341bも同様に、適宜の変数を利用しながら、OS351bからデバイスへのアクセス要求を監視してもよい。
【0237】
図3の例では、1番目のプロファイラはプロファイラ341aであり、1番目のOSはOS351aである。また、2番目のプロファイラはプロファイラ341bであり、2番目のOSはOS351bである。
【0238】
よって、k=1の場合、ステップS104でプロファイラ341aは、今回の期間における監視から判明したOS351aの動作状況から、OS351aについての使用状況情報344を生成する。例えば、プロファイラ341aは、上記のようなカウンタ変数やフラグ変数の値に基づいて、使用状況情報344を生成してもよい。もちろん、図4に関して説明したとおり、デバイスの種類によっては、プロファイラ341aは、ハイパーバイザ320への問い合わせを介して使用状況情報344を生成してもよい。
【0239】
そして、プロファイラ341aは、生成した使用状況情報344を、プロファイル401aの一部として記録する。より具体的には、プロファイラ341aは、図4に示すように、生成した使用状況情報344を「直近の期間」に対応づけて記録する。
【0240】
なお、今まで「直近からT番目の期間」に対応づけられていた使用状況情報344は破棄される。また、1≦j<Tなる各jについて、今まで「直近からj番目の期間」に対応づけられていた使用状況情報344は、ステップS104で、「直近から(j+1)番目の期間」に対応づけられる。
【0241】
例えば、プロファイル401a内の使用状況情報344を格納するためのメモリ領域は、バッファサイズがTのリングバッファであってもよい。この場合、プロファイラ341aは、リングバッファのポインタの値をステップS104で更新してもよい。
【0242】
続いて、ステップS105で仮想電池ドライバ340は、インデックス変数kの値と、情報処理装置300内の仮想マシンの数Nを比較する。仮想マシンの数Nは、換言すればOSの数である。また、第2実施形態では、仮想電池ドライバ340内のプロファイルの数もNである。図3と4には、N=2の例が示されている。
【0243】
もし、k<Nであれば、対応する使用状況情報344がまだ記録されていないOSが残っている。そこで、図6〜7の処理は、ステップS105からステップS106へと移行する。
【0244】
逆に、k≧Nであれば(具体的にはk=Nであれば)、今回の期間に関して、すべてのOSについて、それぞれ対応する使用状況情報344が記録され終わっている。そこで、図6〜7の処理は、ステップS105からステップS107へと移行する。
【0245】
ステップS106で仮想電池ドライバ340は、インデックス変数kを1だけインクリメントする。そして、図6〜7の処理はステップS104へと戻る。
【0246】
さて、ステップS107では、取得部342が電池311の物理残量値を取得する。以下では、物理残量値を「R」とする。
【0247】
取得部342は、例えば、電池I/F203にアクセスし、電池I/F203から物理残量値Rを取得してもよい。取得部342は、取得した物理残量値Rを計算部343に通知する。
【0248】
次に、ステップS108で計算部343は、各プロファイラに通知するために仮想残量値を計算するか否かを決定する。以下では、k番目のOSに通知するための仮想残量値を「r」とする。
【0249】
第2実施形態では、物理残量値Rが所定の閾値Dp未満の場合、計算部343は個々の仮想残量値rを計算しない。その代わり、物理残量値Rが閾値Dp未満の場合、計算部343は、「どのOSに対応する仮想残量値rもゼロである(すなわち、1≦k≦Nなるすべてのkについてr=0)」と見なす。閾値Dpは正の比較的小さな値である。
【0250】
具体的には、R<Dpならば、図6〜7の処理はステップS109に移行する。逆に、R≧Dpならば、図6〜7の処理はステップS113に移行する。
ステップS109で計算部343は、インデックス変数kを1に初期化する。
【0251】
そして、次のステップS110で計算部343は、k番目のプロファイラに、ゼロという仮想残量値rを通知する。すると、k番目のプロファイラは、ゼロという仮想残量値rをk番目のOSに通知する。
【0252】
次に、ステップS111で計算部343は、インデックス変数kの値とOSの数Nを比較する。
【0253】
もし、k<Nであれば、まだゼロという仮想残量値rの通知が済んでいないOSが残っている。そこで、図6〜7の処理は、ステップS111からステップS112へと移行する。
【0254】
逆に、k≧Nであれば(具体的にはk=Nであれば)、すべてのOSに対してそれぞれゼロという仮想残量値rが既に通知されている。よって、図6〜7の処理は、ステップS111からステップS102へと戻る。
【0255】
ステップS112で計算部343は、インデックス変数kを1だけインクリメントする。そして、図6〜7の処理はステップS110へと戻る。
【0256】
さて、ステップS108において物理残量値Rが閾値Dp以上と判断された場合、ステップS113で計算部343は、以下の(17a)と(17b)の条件がともに成立するか否かを判断する。
【0257】
(17a)電池311(つまり電池201)は現在充電中である。
(17b)フラグ347が「電池311の充電中は、物理残量値を最大値と見なす」ということを示している。
【0258】
例えば、計算部343は、電池311が現在充電中か否かについての問い合わせを、電池I/F203に対して発行してもよい。換言すれば、計算部343は、電池I/F203へのアクセスを通じて、「電池311が現在充電中か否か」を判断してもよい。
【0259】
上記の(17a)と(17b)の条件がともに成立する場合、図6〜7の処理はステップS114へと移行する。逆に、(17a)と(17b)の条件のうち少なくとも一方が成立しない場合、図6〜7の処理は、図7のステップS115へと移行する。
【0260】
ステップS114で計算部343は、物理残量値Rが最大値maxRであると見なす。より具体的には、最大値maxRは、電池311の仕様において定められている、物理残量値Rの定義域の最大値である。
【0261】
なお、計算部343は、予め取得部342を介して電池I/F203から最大値maxRを取得してもよい。あるいは、最大値maxRは、定数として不揮発性記憶装置212に予め記憶されていてもよい。
【0262】
取得部342が取得した物理残量値Rを、以上のようにして計算部343が上書きした後、図6〜7の処理は、図7のステップS115へと移行する。
ステップS115で計算部343は、インデックス変数kを1に初期化する。
【0263】
そして、次のステップS116で計算部343は、以下の(18a)と(18b)の情報を用いて、k番目のOSに対応する仮想残量値rを計算する。
【0264】
(18a)k番目のOSに対応する使用状況情報344と、k番目のOSに対応する優先度情報345の、少なくとも一方。
(18b)物理残量値R(具体的には、ステップS107で取得部342により取得された値そのものか、または、当該値を上書きするのにステップS114で使われた最大値maxR)。
【0265】
ステップS115における具体的な計算方法は、実施形態に応じて様々であってよい。例えば、計算部343は、式(1)にしたがって、仮想残量値rを計算してもよい。
【数1】
【0266】
式(1)において、「N」は仮想マシンの数(換言すればOSの数)を表す。また、「R」は物理残量値を表す。
【0267】
式(1)の「Q」は、0<Q≦1を満たす係数である。係数Qの値は、固定されていてもよいし、ユーザ定義可能であってもよい。そして、「e」は、k番目のOSの特性を示す評価値である。
【0268】
式(1)によれば、仮想残量値rは、物理残量値Rに対して単調増加するように定義されている。また、式(1)によれば、仮想残量値rは、全OSの評価値の平均値に対する、k番目のOSの評価値eの割合に対して、単調増加するように定義されている。
【0269】
また、式(1)によれば、係数Qの値が大きいほど、k番目のOSに通知される仮想残量値rが大きい。そして、図5の例示のとおり、多くのOSは、電池の残量が多いほど、より多くの資源を使う傾向がある。したがって、係数Qの値が大きいほど、消費電力量は増え、電池201が早く切れてしまう傾向がある。
【0270】
よって、電池311をより長持ちさせるためには、係数Qが小さな値であることが好ましい。逆に、パフォーマンスを優先するためには、係数Qが1に近い大きめの値であることが好ましい。
【0271】
式(1)の評価値eは、具体的には、k番目のOSについての使用状況情報344と優先度情報345のうち、少なくとも一方に基づく値である。また、計算部343は、使用状況情報344の履歴(つまり、図4における「直近から2番目の期間」から「直近からT番目の期間」までの使用状況情報344)を利用して評価値eを計算してもよい。あるいは、計算部343は、使用状況情報344の履歴を使わずに評価値eを計算してもよい(つまり、図4においてT=1であってもよい)。
【0272】
以下に、評価値eの様々な定義に応じた、仮想残量値rの様々な計算方法について、さらに具体的に説明する。以下の式(2)〜(5)および(7)は、いずれも、式(1)の具体例である。なお、以下では説明の便宜上、次の(19a)〜(19c)のような表記法を用いる。
【0273】
(19a)k番目のOSの優先度を「p」とする。優先度pは、k番目のOSについて優先度情報345により定義された値である。図4の例によれば、p=5でありp=2である。
(19b)k番目の仮想マシンに起因して消費される電力量に関して、直近からj番目の期間について推定される平均電力を「ck,j」とする。平均電力ck,jは、直近からj番目の期間に対応してk番目のプロファイラが生成した使用状況情報344から、計算部343により計算される。平均電力ck,jを計算するための具体的な式の例は、図8〜9とともに後述する。
(19c)計算部343が使用状況情報344の履歴を使わない場合については、簡単化のため、平均電力ck,1を単に「c」とも表記する。
【0274】
以下では説明の便宜上、上記の(19a)〜(19c)の表記法を用いて、計算部343による仮想残量値rの計算方法の具体例について説明する。
【0275】
まず、計算部343は、k番目のOSについての使用状況情報344を参照して、平均電力ck,jを計算する。
【0276】
使用状況情報344の履歴を使わない場合、計算部343は、平均電力c(=ck,1)と優先度pを用いて、例えば式(2)にしたがって仮想残量値rを計算してもよい。式(2)は、e=pの場合を示す。
【数2】
【0277】
また、計算部343は、式(3)と(4)に示すように、使用状況情報344と優先度情報345の一方のみを用いて仮想残量値rを計算してもよい。式(3)はe=cの場合を示し、式(4)はe=pの場合を示す。
【数3】
【数4】
【0278】
もちろん、計算部343は、使用状況情報344の履歴を用いてもよい。例えば、計算部343は、使用状況情報344の履歴と優先度情報345の双方を用いて、式(5)にしたがって仮想残量値rを計算してもよい。式(5)は、評価値eが式(6)のように表される場合を示す。
【数5】
【数6】
【0279】
計算部343は、優先度情報345を使わずに、使用状況情報344の履歴を用いて、式(7)にしたがって仮想残量値rを計算してもよい。式(7)は、評価値eが式(8)のように表される場合を示す。
【数7】
【数8】
【0280】
もちろん、計算部343は、上記に例示した以外の式にしたがって、図7のステップS116において仮想残量値rを計算してもよい。
【0281】
例えば、仮想残量値rの定義域の最大値が決められていてもよい。以下では当該最大値を「maxr」とする。
【0282】
例えば、任意のkについて「maxr=maxR」と定義されていてもよい。この「maxr=maxR」という定義は、特に後述の第2モードに好適である。あるいは、優先度情報345が使われる場合は、物理残量値Rの最大値maxRと優先度pに応じて、仮想残量値rの最大値maxrが静的に定義されていてもよい。
【0283】
計算部343は、例えば、式(1)の代わりに式(9)を用いて、仮想残量値rを計算してもよい。なお、上記のとおり、式(2)〜(5)および(7)は、いずれも、式(1)の具体例である。よって、式(9)の評価値eを適宜定義することによって、式(1)を式(9)で置き換えるのと同様にして、式(2)〜(5)および(7)の各々も別の式に置き換えることが可能である。
【数9】
【0284】
仮想残量値rの計算後、次のステップS117で計算部343は、仮想残量値rと閾値Dvを比較する。閾値Dvは正の比較的小さな値である。
【0285】
もし、r<Dvならば、図6〜7の処理はステップS118に移行する。逆に、r≧Dvならば、図6〜7の処理はステップS119に移行する。
【0286】
ステップS118で計算部343は、実際にステップS116で計算した値に関わらず、k番目のプロファイラに、ゼロという仮想残量値rを通知する。つまり、計算部343は、仮想残量値rをゼロと再評価する。すると、k番目のプロファイラは、ゼロという仮想残量値rをk番目のOSに通知する。そして、図6〜7の処理はステップS125へと移行する。
【0287】
他方、r≧Dvの場合、ステップS119で計算部343は、ステップS113と同様の方法により、現在電池311が充電中であるか否かを判断する。もし、電池311が現在充電中でなければ、図6〜7の処理はステップS120へと移行する。逆に、電池201が現在充電中であれば、図6〜7の処理はステップS121へと移行する。
【0288】
ステップS120で計算部343は、k番目のプロファイラに、ステップS116で計算した仮想残量値rを通知する。すると、k番目のプロファイラは、通知された仮想残量値rをk番目のOSに通知する。そして、図6〜7の処理はステップS125へと移行する。
【0289】
ステップS121で計算部343は、k番目のOSについてのモード情報346を参照する。以下、第1〜第3モードについて説明する。
【0290】
第1モードは、物理的な電池311(つまり電池201)が充電されている間は特定の値をOSに通知するモードである。具体的には、第1モードにおける上記「特定の値」は、仮想残量値rの定義域の最大値である。仮想残量値rの定義域の最大値maxrは、仮想残量値rの計算に使われる式によって異なり得る。
【0291】
例えば、式(9)が使われる場合、仮想残量値rの定義域の最大値maxrは、最大値maxrとして予め任意に決められた正の値である。また、式(4)が使われる場合、仮想残量値rの定義域の最大値maxrは、物理残量値Rの定義域の最大値maxRと、各OSの優先度pに応じて決まる。
【0292】
式(2)が使われる場合、仮想残量値rの定義域の最大値maxrは、各仮想マシンに対応する電力cの最小値による。例えば、各仮想マシンに対応する電力cの最小値がゼロであるとする。この場合、式(2)においてi≠kなる各iについてc=0とし、かつR=maxRとすると、r=Q・maxR・Nである。したがって、maxr=Q・maxR・Nである。
【0293】
式(3)、(5)、または(7)が使われる場合の最大値maxrも、式(2)が使われる場合と同様である。
【0294】
電池311の充電中は、消費電力量を低く抑えるための制御をOSが特に行わなくても、電池切れの心配はない。そこで、電池311の充電中は消費電力量の抑制よりもパフォーマンス向上を優先するために、第1モードが使われてもよい。
【0295】
第2モードは、物理的な電池311が充電されている間は物理残量値Rを仮想残量値rとしてOSに通知するモードである。OSの中には、「充電完了まであとX分」もしくは「Y%充電完了」のようなメッセージ(または、そのようなメッセージに相当するアイコン)を表示するための計算を行うものがある。当該計算が正確に行われるようにするために、当該計算を行うOSは、第2モードに設定されていてもよい。
【0296】
なお、仮想電池ドライバ340は、当該計算を行うOSに対して、当該計算に用いるための値として、物理残量値Rの定義域の最大値maxRを予め通知しておいてもよい。すると、第2モードのOSは、予め通知された最大値maxRと、充電中の電池311の現在の物理残量値Rとから、充電完了までにかかる時間、または現在の充電率を計算することができる。
【0297】
第3モードは、物理的な電池311が充電中の場合と、物理的な電池311が充電中ではない場合を区別しないモードである。第1モードには電池311の充電中のパフォーマンスの向上という効果があり、第2モードには上記計算の正確性の向上という効果がある。しかし、もちろん、第3モードも利用可能である。
【0298】
さて、ステップS121におけるモード情報346の参照の結果、k番目のOSのモードが第1モードと判明した場合、図6〜7の処理はステップS122へと移行する。また、k番目のOSのモードが第2モードの場合、図6〜7の処理はステップS123へと移行する。そして、k番目のOSのモードが第3モードの場合、図6〜7の処理はステップS124へと移行する。
【0299】
k番目のOSのモードが第1モードの場合、ステップS122で計算部343は、実際にステップS116で計算した値に関わらず、k番目のプロファイラに、k番目の仮想マシンに対応する仮想残量値rの定義域の最大値maxrを通知する。つまり、計算部343は、仮想残量値rを最大値maxrと見なす。すると、k番目のプロファイラは、通知された最大値maxrをk番目のOSに通知する。そして、図6〜7の処理はステップS125へと移行する。
【0300】
なお、上記のとおり、仮想残量値rの定義域の最大値maxrは、予め決められた定数でもよいし、仮想残量値rの式に応じて決まる値であってもよい。最大値maxrは、例えば不揮発性記憶装置212に予め記憶されていてもよい。そして、最大値maxrは、不揮発性記憶装置212から、仮想電池ドライバ340に割り当てられたメモリ空間内の記憶領域へと予め読み出されていてもよい。
【0301】
さて、k番目のOSのモードが第2モードの場合、ステップS123で計算部343は、k番目のプロファイラに、仮想残量値rとして物理残量値Rを通知する。なお、ステップS123で仮想残量値rとして通知される物理残量値Rは、ステップS107で取得部342が取得した値そのものの場合もあるし、ステップS114で最大値maxRに書き換えられた物理残量値Rの場合もある。
【0302】
つまり、電池311が充電中のとき、計算部343は、仮想残量値rを、電池311の現在の実際の物理残量値Rと同じと見なす場合もある。また、電池311が充電中のとき、計算部343は、仮想残量値rを、物理残量値Rの定義域の最大値maxRと同じと見なす場合もある。
【0303】
いずれにせよ、計算部343がk番目のプロファイラに仮想残量値rとして物理残量値Rを通知すると、k番目のプロファイラは、仮想残量値rとして物理残量値Rをk番目のOSに通知する。そして、図6〜7の処理はステップS125へと移行する。
【0304】
さて、k番目のOSのモードが第3モードの場合、ステップS124で計算部343は、k番目のプロファイラに、ステップS116で計算した仮想残量値rを通知する。すると、k番目のプロファイラは、通知された仮想残量値rをk番目のOSに通知する。そして、図6〜7の処理はステップS125へと移行する。
【0305】
さて、ステップS125は、k番目のプロファイラがステップS118、S120、S122、S123、またはS124においてk番目のOSに仮想残量値rを通知した後に、実行される。具体的には、ステップS125で計算部343は、インデックス変数kの値とOSの数Nを比較する。
【0306】
もし、k<Nであれば、まだ仮想残量値rの通知が済んでいないOSが残っている。そこで、図6〜7の処理は、ステップS125からステップS126へと移行する。
【0307】
逆に、k≧Nであれば(具体的にはk=Nであれば)、すべてのOSに対してそれぞれ仮想残量値rが既に通知されている。よって、図6〜7の処理は、ステップS125から図6のステップS102へと戻る。
【0308】
ステップS126で計算部343は、インデックス変数kを1だけインクリメントする。そして、図6〜7の処理はステップS116へと戻る。
【0309】
以上説明した図6〜7の処理により、定期的に各OSに仮想残量値が通知される。そして、各OSは、通知された仮想残量値と図5のようなルールセットにしたがって、電力に関する適宜の制御を実行する。
【0310】
続いて、図8〜9を参照して、具体的な計算例について説明する。図8は、第2実施形態において履歴を使わずに仮想残量値rを計算する例を示す図である。また、図9は、第2実施形態において履歴を使って仮想残量値rを計算する例を示す図である。
【0311】
具体的には、図8〜9には、5つの計算例601〜605が例示されている。計算例601は、仮想残量値が利用されない第3比較例に関する例である。
【0312】
計算例602は、第2実施形態において式(2)が利用され、式(2)においてQ=0.1である場合の例である。計算例603は、第2実施形態において式(2)が利用され、式(2)においてQ=1である場合の例である。つまり、計算例602と603を比べると、計算例602は電池311を長持ちさせることを重視する例であり、計算例603はパフォーマンスを重視する例である。
【0313】
計算例604は、第2実施形態において式(5)が利用され、式(5)においてT=2かつQ=0.1である場合の例である。計算例605は、第2実施形態において式(5)が利用され、式(5)においてT=2かつQ=1である場合の例である。つまり、計算例604と605を比べると、計算例604は電池311を長持ちさせることを重視する例であり、計算例605はパフォーマンスを重視する例である。
【0314】
具体的に計算例601〜605について参照する前に、いくつかの仮定について説明する。図8〜9の例では、以下の(20a)〜(20m)のように仮定する。
【0315】
(20a)図4の例とは異なり、OS351aに対応する(つまり仮想マシン350aに対応する)優先度pは、1であるものとする。また、図4の例とは異なり、OS351bに対応する(つまり仮想マシン350bに対応する)優先度pは、3であるものとする。
(20b)上記(14f)のように、クアッドコアの物理CPUのうち2つのコアが仮想マシン350aの2つの仮想CPUコアに割り当てられ、残りの2つのコアが仮想マシン350bの2つの仮想CPUコアに割り当てられるものとする。この場合、仮想マシン350aと仮想マシン350bは物理CPUコアを共有しない。よって、ハイパーバイザ320は、CPUコアのクロック周波数を変更するための命令をOS351aまたは351bから受け取ると、命令にしたがって実際にクロック周波数を変更するものとする。
(20c)1つの物理CPUコアを1GHzで動作させ、かつ100%の使用率で命令を実行させるための電力は、1Wであるものとする。また、1つの物理CPUコアを500MHzで動作させ、かつ100%の使用率で命令を実行させるための電力は、0.5Wであるものとする。そして、1つの物理CPUコアを100MHzで動作させ、かつ100%の使用率で命令を実行させるための電力は、0.1Wであるものとする。
(20d)或る期間に物理CPUコアによって消費される電力量は、当該期間における物理CPUコアの使用率に比例するものとする。ここでは説明の簡単化のため、仮想マシン350aの2つの仮想CPUコアに割り当てられた2つの物理CPUコアの使用率は、どちらも常に100%であるものとする。同様に、仮想マシン350bの2つの仮想CPUコアに割り当てられた2つの物理CPUコアの使用率は、どちらも常に100%であるものとする。
(20e)仮想マシン350aの動作に起因する消費電力量と、仮想マシン350bの動作に起因する消費電力量の和が、情報処理装置300全体の消費電力量に等しいとする。また、簡単化のため、CPU204とGPU205とタッチパネル206とWiFiモジュール216以外のデバイスの動作にかかる電力は、無視することができるものとする。
(20f)OS351aは図5のルールセット500を使い、OS351bは図5のルールセット540を使うものとする。なお、図8〜9のテーブル中では、OSが適用するルールが切り換わる箇所の横罫線が、太く強調されている。
(20g)WiFiモジュール216による通信により消費される電力量は、0.01Wh/kBであるものとする。
(20h)アプリケーション352aからの要求に応じて、OS351aは、仮想マシン350aの仮想WiFiモジュールを介してフレームを送信または受信する。このような仮想マシン350a用の仮想WiFiモジュールを介した通信のデータレートは、通常は、1000kB/hであるものとする。同様に、仮想マシン350b用の仮想WiFiモジュールを介した通信のデータレートも、通常は、1000kB/hであるものとする。なお、データレートは、ルール508または547の適用により、制限される場合がある。
(20i)デュアルコアの物理GPUが1台あるものとする。そして、第1コアが仮想マシン350a用の仮想GPUに割り当てられており、第2コアが仮想マシン350b用の仮想GPUに割り当てられているものとする。
(20j)GPUのモードには、「通常モード」と「省電力モード」の2種類があるものとする。例えば、2種類のモード間でGPUのクロック周波数が異なっていてもよい。また、物理GPUコアを通常モードと省電力モードで動作させるための電力は、それぞれ、2Wと1Wであるものとする。使用状況情報344では、物理GPUコアに関して、図4のように「ON」または「OFF」が記録されるのではなく、モードが記録されるものとする。
(20k)OS351aと351bは、仮想GPUのモードを変更するための命令(例えばハイパーバイザコール)を発行してもよい。仮想マシン350aと350bは物理GPUコアを共有しないので、ハイパーバイザ320は、命令にしたがって、仮想GPUに対応する物理GPUコアのモードを実際に変更するものとする。
(20l)或る仮想マシンにおける全プロセスがサスペンド状態のとき、当該仮想マシンの実行にかかる電力は、全デバイスを合わせて0.01Wであるものとする。また、OSが強制的にスリープしたときは、仮想マシンの実行にかかる電力は0Wであるものとする。
(20m)OS351aと351bの少なくとも一方が、仮想ディスプレイのバックライトを減光するための命令を発行すると、ハイパーバイザ320が、物理デバイスであるタッチパネル206のバックライトを実際に減光するものとする。タッチパネル206のバックライトを通常の強さで発光させるための電力は4Wであり、減光されたレベルの発光をさせるための電力は1Wであるものとする。また、すべてのOSが強制的にスリープしたときは、タッチパネル206への電力供給が遮断されるものとする。
【0316】
さて、計算例601に示す第3比較例では、同じ物理残量値RがOS351aと351bに通知される。他方、第2実施形態では、OS351aと351bには、仮想残量値rとrがそれぞれ通知される。しかし、OS351aと351bは、通知された値が物理残量値なのか仮想残量値なのかを認識せず、単に、通知された値にしたがって適宜のルールを適用する。
【0317】
20Wh以上の電池残量がOS351aに通知された場合、図5によれば、OS351aはルール504〜505を適用する。よって、上記の仮定(20a)〜(20m)によれば、ルール504〜505の適用後の仮想マシン350aの実行にかかる電力は、下記(21a)〜(21d)の値の和であり、具体的には、13.5(=1+0.5+2+10)Wである。
【0318】
(21a)物理CPUの第1コア用の1W(物理CPUの第1コアは、仮想マシン350a用の仮想CPUの第1コアに割り当てられており、1GHzで動作し、使用率は100%である)。
(21b)物理CPUの第2コア用の0.5W(物理CPUの第2コアは、仮想マシン350a用の仮想CPUの第2コアに割り当てられており、500MHzで動作し、使用率は100%である)。
(21c)物理GPUの第1コア用の2W(物理GPUの第1コアは、仮想マシン350a用の仮想GPUに割り当てられており、通常モードで動作する)。
(21d)WiFiモジュール216用の10W(=1000[kB/h]×0.01[Wh/kB])。
【0319】
また、5Wh以上20Wh未満の電池残量がOS351aに通知された場合、図5によれば、OS351aはルール506〜509を適用する。よって、上記の仮定(20a)〜(20m)によれば、ルール506〜509の適用後の仮想マシン350aの実行にかかる電力は、下記(22a)〜(22d)の値の和であり、具体的には、2.61(=0.5+0.1+2+0.01)Wである。
【0320】
(22a)物理CPUの第1コア用の0.5W(物理CPUの第1コアは、仮想マシン350a用の仮想CPUの第1コアに割り当てられており、500MHzで動作し、使用率は100%である)。
(22b)物理CPUの第2コア用の0.1W(物理CPUの第2コアは、仮想マシン350a用の仮想CPUの第2コアに割り当てられており、100MHzで動作し、使用率は100%である)。
(22c)物理GPUの第1コア用の2W(物理GPUの第1コアは、仮想マシン350a用の仮想GPUに割り当てられており、通常モードで動作する)。
(22d)WiFiモジュール216用の0.01W(=1[kB/h]×0.01[Wh/kB])。
【0321】
また、5Wh未満の電池残量がOS351aに通知された場合、図5によれば、OS351aはルール510を適用する。よって、上記の仮定(20a)〜(20m)によれば、ルール510の適用後の仮想マシン350aの実行にかかる電力は、0Wである。
【0322】
さて、30Wh以上の電池残量がOS351bに通知された場合、図5によれば、OS351bはルール544〜545を適用する。よって、上記の仮定(20a)〜(20m)によれば、ルール544〜545の適用後の仮想マシン350bの実行にかかる電力は、下記(23a)〜(23d)の値の和であり、具体的には、13(=1+0+2+10)Wである。
【0323】
(23a)物理CPUの第3コア用の1W(物理CPUの第3コアは、仮想マシン350b用の仮想CPUの第1コアに割り当てられており、1GHzで動作し、使用率は100%である)。
(23b)物理CPUの第4コア用の0W(物理CPUの第4コアは、仮想マシン350b用の仮想CPUの第2コアに割り当てられているが、ルール545の適用により停止されている)。
(23c)物理GPUの第2コア用の2W(物理GPUの第2コアは、仮想マシン350b用の仮想GPUに割り当てられており、通常モードで動作する)。
(23d)WiFiモジュール216用の10W(=1000[kB/h]×0.01[Wh/kB])。
【0324】
また、7.5Wh以上30Wh未満の電池残量がOS351bに通知された場合、図5によれば、OS351bはルール544〜547を適用する。よって、上記の仮定(20a)〜(20m)によれば、ルール544〜547の適用後の仮想マシン350bの実行にかかる電力は、下記(24a)〜(24d)の値の和であり、具体的には、3(=1+0+2+0)Wである。
【0325】
(24a)物理CPUの第3コア用の1W(物理CPUの第3コアは、仮想マシン350b用の仮想CPUの第1コアに割り当てられており、1GHzで動作し、使用率は100%である)。
(24b)物理CPUの第4コア用の0W(物理CPUの第4コアは、仮想マシン350b用の仮想CPUの第2コアに割り当てられているが、ルール545の適用により停止されている)。
(24c)物理GPUの第2コア用の2W(物理GPUの第2コアは、仮想マシン350b用の仮想GPUに割り当てられており、通常モードで動作する)。
(24d)WiFiモジュール216用の0W(ルール547の適用により、WiFiモジュール216を使った通信は行われない)。
【0326】
また、7.5Wh未満の電池残量がOS351bに通知された場合、図5によれば、OS351bはルール544〜548を適用する。よって、上記の仮定(20a)〜(20m)によれば、ルール544〜548の適用後の仮想マシン350bの実行にかかる電力は、下記(25a)〜(25d)の値の和であり、具体的には、2(=1+0+1+0)Wである。
【0327】
(25a)物理CPUの第3コア用の1W(物理CPUの第3コアは、仮想マシン350b用の仮想CPUの第1コアに割り当てられており、1GHzで動作し、使用率は100%である)。
(25b)物理CPUの第4コア用の0W(物理CPUの第4コアは、仮想マシン350b用の仮想CPUの第2コアに割り当てられているが、ルール545の適用により停止されている)。
(25c)物理GPUの第2コア用の1W(物理GPUの第2コアは、仮想マシン350b用の仮想GPUに割り当てられており、省電力モードで動作する)。
(25d)WiFiモジュール216用の0W(ルール547の適用により、WiFiモジュール216を使った通信は行われない)。
【0328】
なお、図5のルールセット540は強制スリープに関するルールを含まない。そのため、OS351aと351bが双方とも強制スリープすることはない。したがって、上記の仮定(20f)と(20m)より、タッチパネル206への電力供給は遮断されない。
【0329】
また、図5のルールセット500は、バックライトの減光に関するルールを含まない。そのため、タッチパネル206用の電力は、OS351aに通知される電池残量に依存して変化することはない。
【0330】
したがって、OS351bがルール546を適用しなければ(つまりOS351bに30Wh以上の電池残量が通知されれば)、タッチパネル206を動作させるための電力は4Wである。逆に、OS351bがルール546を適用すれば(つまりOS351bに30Wh未満の電池残量が通知されれば)、タッチパネル206を動作させるための電力は1Wである。
【0331】
さて、以上の説明に基づいて、続いて図8〜9の計算例601〜605について説明する。
図8〜9において、「t」は、電池311がフル充電された状態で情報処理装置300に電源が入れられたときを基準とする時刻である。換言すれば、「t」は、電池311がフル充電された状態で情報処理装置300に電源が入れられてから経過した時間の長さを示す。なお、説明の便宜上、図8〜9の計算例601〜605は、いずれも、図6のステップS102の単位時間が1時間である場合の例である。しかし、もちろん単位時間はより短い時間であってもよい。
【0332】
図8〜9において、「R」は、時刻tにおける電池311の物理残量値を示す。なお、図8〜9の例では、t=0のときR=100なので、時刻tの上記定義より、maxR=100である。
【0333】
また、時刻tから時刻(t+1)までの期間において、仮想マシン350aの実行にかかる電力は一定と見なせる。図8〜9ではその一定の電力が「c」と表されている。つまり、時刻tにOS351aに通知された電池残量と、ルールセット500に基づいて、時刻tにOS351aが行う制御によれば、時刻tから時刻(t+1)の期間では、仮想マシン350aの実行にかかる電力は一定値cである。
【0334】
同様に、時刻tから時刻(t+1)までの期間において、仮想マシン350bの実行にかかる電力は一定と見なせる。図8〜9ではその一定の電力が「c」と表されている。
【0335】
また、時刻tから時刻(t+1)までの期間において、タッチパネル206を動作させるための電力も一定と見なせる。図8〜9ではその一定の電力が「c」と表されている。
【0336】
そして、上記(20e)の仮定より、時刻tから時刻(t+1)までの期間における情報処理装置300全体の消費電力量は、時刻tの行の電力cとcとcを用いて、
(c+c+c)[W]×1[h]
と表せる。時刻(t+1)の物理残量値Rは、時刻tの物理残量値Rよりも、この消費電力量の分だけ少なくなっている。
【0337】
例えば、図8の計算例601は、仮想残量値が使われない第3比較例を示す。
計算例601に示すように、第3比較例では、OS351aに通知された物理残量値Rが20Wh以上の間は(つまりt=0の行からt=2の行までは)、c=13.5W(すなわち上記(21a)〜(21d)の和)である。また、OS351aに通知された物理残量値Rが5Wh以上20Wh未満の間は(つまりt=3の行では)、c=2.61W(すなわち上記(22a)〜(22d)の和)である。そして、OS351aに通知された物理残量値Rが5Wh未満のときは(つまりt=4の行では)、c=0Wである(ルール510が適用されるため)。
【0338】
また、第3比較例では、OS351bに通知された物理残量値Rが30Wh以上の間は(つまりt=0の行からt=2の行までは)、c=13W(すなわち上記(23a)〜(23d)の和)であり、c=4Wである。また、OS351bに通知された物理残量値Rが7.5Wh以上30Wh未満の間は(つまりt=3の行では)、c=3W(すなわち上記(24a)〜(24d)の和)であり、c=1Wである。そして、OS351bに通知された物理残量値Rが7.5Wh未満のときは(つまりt=4の行では)、c=2W(すなわち上記(25a)〜(25d)の和)であり、c=1Wである。
【0339】
計算例601に示すように、第3比較例では、時刻t=5のときには電池切れである。それに対して、第2実施形態についての計算例602〜605では、電池切れは時刻t=6以降に起きる。
【0340】
具体的には、計算例602〜605では、上記(20a)のような優先度に応じた仮想残量値rとrがそれぞれOS351aと351bに通知される。よって、相対的に優先度の高い仮想マシン350bの稼働可能な時間が、第3比較例の計算例601よりも長い。
【0341】
つまり、計算例602〜605では、相対的に優先度の低いOS351aには、小さな仮想残量値rが通知される。そのため、仮想マシン350aからのデバイスの利用をOS351aが抑制する傾向は、計算例601よりも計算例602〜605において、より強い。その結果、計算例602〜605では、相対的に優先度の低い仮想マシン350aに分配される電力は少なくなり、相対的に優先度の高い仮想マシン350bの稼働可能な時間が長くなる。
【0342】
なお、計算例602〜605のいずれにおいても、次の(26a)〜(26g)のことは共通である。
【0343】
(26a)OS351aに通知された仮想残量値rが20Wh以上の間は(例えば計算例603のt=0の行からt=2の行までは)、c=13.5W(すなわち上記(21a)〜(21d)の和)である。
(26b)OS351aに通知された仮想残量値rが5Wh以上20Wh未満の間は(例えば計算例602のt=0の行や計算例604のt=0の行では)、c=2.61W(すなわち上記(22a)〜(22d)の和)である。
(26c)OS351aに通知された仮想残量値rが5Wh未満のときは(例えば計算例602のt=1以降の行では)、c=0Wである(ルール510が適用されるため)。
(26d)OS351bに通知された仮想残量値rが30Wh以上の間は(例えば計算例605のt=0の行からt=2の行までは)、c=13W(すなわち上記(23a)〜(23d)の和)であり、c=4Wである。
(26e)OS351bに通知された仮想残量値rが7.5Wh以上30Wh未満の間は(例えば計算例602のt=0の行からt=14の行までは)、c=3W(すなわち上記(24a)〜(24d)の和)であり、c=1Wである。
(26f)OS351bに通知された仮想残量値rが7.5Wh未満のときは(例えば計算例603のt=5の行では)、c=2W(すなわち上記(25a)〜(25d)の和)であり、c=1Wである。
(26g)t=0の行における仮想残量値rとrは、図6のステップS101の初期化の際に計算部343により計算され、プロファイラ341aと341bによりそれぞれOS351aと351bに通知された値である。ステップS101の初期化の際にはまだ使用状況情報344が蓄積されていないので、計算部343は、優先度情報345と物理残量値Rを使って、式(4)にしたがって仮想残量値rとrを計算してもよい。計算例602〜605には、以上のようにして式(4)にしたがってt=0のときに計算された仮想残量値rとrが示されている。
【0344】
ここで、計算例602〜605で上記(26a)のように表される電力cと、図5のルールセットと、図6〜7の処理との間の関係について補足説明する。他の(26b)〜(26f)の各々と図5〜7との間の関係も、(26a)と図5〜7との間の関係と同様である。
【0345】
図6〜7の処理によりプロファイラ341aが時刻tにOS351aに通知した仮想残量値rが20Wh以上である場合、OS351aは、通知に応じて、図5のルール504〜505を適用する。ルール504〜505の適用は、ほぼ時刻tに行われたものと見なせる。
【0346】
また、上記のとおり、図8〜9の計算例601〜605においては、図6のステップS102の単位時間が1時間である。この単位時間の間は、新たな仮想残量値rがOS351aに通知されない。そのため、この単位時間の間は、OS351aも適用するルールを変えない。よって、時刻tから時刻(t+1)までの単位時間の間、仮想マシン350aの実行にかかる電力も、一定と見なせる。つまり、20Wh以上の仮想残量値rをプロファイラ341aがOS351aに通知した後の、図6のステップS102の単位時間が経過する間は、仮想マシン350aの実行にかかる電力cは、(26a)に述べたとおり、13.5Wという一定値と見なせる。
【0347】
ところで、13.5Wという電力は、上記のとおり(21a)〜(21d)に示した電力の和である。そして、(21a)〜(21d)に示した電力は、具体的には、計算部343が、ほぼ時刻(t+1)と見なせるタイミングでステップS116において計算する値である。
【0348】
具体的には、上記のステップS102での単位時間の経過後、ほぼ時刻(t+1)と見なせるタイミングにおいてステップS104が実行される。ステップS104で生成されるプロファイル401aの使用状況情報344は、以下の(27a)〜(27f)に示す「1GHz」、「100%」、「500MHz」、「100%」、「通常モード」、および「1000kB」という値を含む。
【0349】
(27a)仮想マシン350a用の仮想CPUの第1コアに割り当てられている物理CPUの第1コアが、今回の単位時間の間(つまり時刻tから時刻(t+1)までの期間)は1GHzで動作していた。
(27b)物理CPUの第1コアの、仮想マシン350aに起因する使用率(つまりOS351aとアプリケーション352aに起因する使用率)は、今回の単位時間において100%であった。
(27c)仮想マシン350a用の仮想CPUの第2コアに割り当てられている物理CPUの第2コアが、今回の単位時間の間は500MHzで動作していた。
(27d)物理CPUの第2コアの、仮想マシン350aに起因する使用率は、今回の単位時間において100%であった。
(27e)仮想マシン350a用の仮想GPUに割り当てられている物理GPUの第1コアは、今回の単位時間の間は通常モードで動作していた。
(27f)WiFiモジュール216を介して今回の単位時間の間に行われた通信のうち、仮想マシン350aが送信元または送信先である通信のデータ量は、1000kB(=1000[kB/h]×1[h])であった。
【0350】
そして、ステップS104の実行のタイミングとステップS116の実行のタイミングの差はごくわずかであるから、ステップS116もほぼ時刻(t+1)に実行されると見なせる。つまり、ほぼ時刻(t+1)にステップS116で、計算部343は、(27a)〜(27f)に示した値を含む使用状況情報344を用いて、電力cを13.5Wと計算する。
【0351】
計算部343が電力cを計算する具体的な方法は、(21a)〜(21d)を参照して説明したように、加算を含む。つまり、計算部343は、各物理デバイスに対応する電力から電力cを計算する。計算部343は、例えば上記の仮定(20c)、(20d)、(20g)、(20h)、(20j)などに例示したような特定の電力計算モデルにしたがって、各物理デバイスに対応する電力を計算する。
【0352】
もちろん、計算部343は、実施形態に合った電力計算モデルを表す適宜の式にしたがって、各物理デバイスに対応する電力および合計の電力cを計算することが好ましい。例えば、計算部343は、上記(20d)の方法(つまり、クロック周波数に応じた電力に、単に使用率を掛ける方法)とは異なる方法にしたがって、物理CPUコア用の電力を計算してもよい。
【0353】
電力cと同様に、計算部343は、ほぼ時刻(t+1)にステップS116で、電力cも計算する。そして、計算部343は、電力cとcを使って、新たな仮想残量値rを計算する。
【0354】
また、図7に示すように、ステップS116は各OSに対応して実行される。つまり、計算部343は、新たな仮想残量値rも同様に計算する。ここで、図7のステップS115〜S126の繰り返しループの実行にかかる時間はごくわずかである。よって、「ほぼ時刻(t+1)には、新たな仮想残量値rとrが、計算され、必要に応じて再評価され、OS351aと351bにそれぞれ通知される」と見なせる。
【0355】
ここで、図8〜9の各計算例のテーブルでは、時刻tから時刻(t+1)の期間における電力は、時刻tの行に書かれている。よって、以上のようにしてほぼ時刻(t+1)にステップS116で計算された電力cを示す「13.5W」という値が、図8〜9の各計算例のテーブルでは、時刻tの行に書かれている。
【0356】
よって、上記(26a)に要約したとおり、時刻tの行の仮想残量値rが20Wh以上の場合、同じ行の電力cは13.5Wである。上記(26b)〜(26f)の各々についても同様に、「計算例602〜605における電力cとcは、計算部343による計算結果を示している」とも言える。
【0357】
ところで、上記のとおり、計算例604と605は、式(5)を利用する例である。より具体的には、計算例604と605は、式(5)においてT=2の場合の例である。
【0358】
ところが、t=1のときには、直近の期間(つまりt=0からt=1までの単位時間)の使用状況情報344しか蓄積されておらず、直近からT番目(つまり直近から2番目)の期間の使用状況情報344は未蓄積である。そのため、計算例604と605のt=1の行における仮想残量値rとrは、T=1と見なして式(5)にしたがって計算された値(換言すれば、式(2)にしたがって計算された値)である。
【0359】
つまり、計算部343は、式(5)を利用する場合であっても、所定の個数(T個)の期間にそれぞれ対応する使用状況情報344が蓄積されるまでは、T個未満の期間の使用状況情報344のみを利用して仮想残量値を計算してもよい。
【0360】
続いて、第3〜第5実施形態について図10〜13を参照して説明する。なお、以下の説明においては、第2実施形態との共通点に関しては、図3〜7での参照符号を用いて説明を行うことがある。
【0361】
第3実施形態は、図3のハイパーバイザ320が図11の処理を実行する点において第2実施形態と異なる。しかし、他の点では、第3実施形態は第2実施形態と同様である。
【0362】
また、第4実施形態は、ハイパーバイザ320が図11の処理の代わりに図12の処理を行う点で第3実施形態と異なる。しかし、他の点では、第4実施形態は第3実施形態と同じである。
【0363】
第5実施形態は、第4実施形態と類似だが、第5実施形態の仮想電池ドライバ340では、計算部343とプロファイラ341a〜341bが省略される。よって、第5実施形態では、計算部343が使う各種情報(つまり、使用状況情報344、優先度情報345、モード情報346、およびフラグ347)も省略される。その代わり、第5実施形態では、取得部342が、取得した物理残量値RをOS351aと351bのそれぞれに通知する。通知は、所定の間隔で行われてもよい。
【0364】
以下では、まず第3〜第5実施形態の共通点について説明する。
第3〜第5実施形態では、複数の仮想マシン350a〜350bの各々にハイパーバイザ320が提供する仮想ハードウェアの構成が、電池311の物理残量値または仮想残量値に応じて、動的に変更される。換言すれば、第3〜第5実施形態では、ハイパーバイザ320が、物理残量値または仮想残量値に応じて、仮想ハードウェア要素のホットアドまたはホットリムーブを実行する。
【0365】
ホットリムーブされた仮想ハードウェア要素は、仮想マシンからアクセスされない。したがって、ハイパーバイザ320は、ホットリムーブした仮想ハードウェア要素(例えば仮想CPU)に今まで割り当てていた物理ハードウェア要素(例えば物理CPU内のコア)への電力供給を、遮断してもよい。物理ハードウェア要素への電力供給を断つことにより、情報処理装置300全体での消費電力量は低減する。
【0366】
もちろん、複数の仮想マシンそれぞれの仮想ハードウェア要素に、同じ1つの物理ハードウェア要素が割り当てられている場合もあり得る。この場合、ハイパーバイザ320は、ある1つの仮想マシンから仮想ハードウェア要素をホットリムーブしたら、ホットリムーブした仮想ハードウェア要素に割り当てている物理ハードウェア要素の動作周波数を、下げてもよい。動作周波数の低減により、消費電力量も低減する。
【0367】
このように、第3〜第5実施形態では、仮想ハードウェア構成の動的な変更により、情報処理装置300全体での消費電力量の削減が図られる。消費電力量の削減により、電池311は長持ちする(つまり、情報処理装置300の可用時間が長くなる)。以下、図10〜13を参照して、第3〜第5実施形態についてさらに詳しく説明する。
【0368】
図10は、第3〜第5実施形態で使われる割り当てルールの例を示す図である。全仮想マシンに共通の割り当てルールが使われてもよいし、仮想マシンごとに異なる割り当てルールが使われてもよい。第3〜第5実施形態では、仮想マシンごとに異なる割り当てルールが使われる。
【0369】
割り当てルールは、各仮想ハードウェア要素を仮想マシンに対して提供するか否かを電池残量ごとに規定するルールである。実施形態によって、割り当てルールの定義に使われる電池残量は、仮想残量でもよいし、物理残量でもよい。具体的には、第3実施形態では仮想残量が使われ、第4実施形態と第5実施形態では物理残量が使われる。
【0370】
図10では、仮想ハードウェア要素として、CPUの第1〜第2コア、GPUの第1〜第4コア、USBコントローラ、およびWiFiモジュールが例示されている。もちろん、ディスプレイやスピーカなどの他の仮想ハードウェア要素がさらにあってもよいが、説明の便宜上図10では、他のハードウェア要素はまとめて「その他」と表されている。
【0371】
なお、図10の例では、割り当てルール701と702のいずれにおいても、メモリの割り当てについて明示はされていない。しかし、図10の例では、「メモリは電池残量によらず常にどの仮想マシンに対しても提供される」と暗黙的に予め決められているものとする。実施形態によっては、各仮想マシンに割り当てるメモリの容量を電池残量に応じて変更するために、割り当てルールで定義される仮想ハードウェア要素の1つが仮想メモリモジュールであってもよい。
【0372】
また、紙幅の都合上、図10ではUSBコントローラが「USB」と略記され、WiFiモジュールが「WiFi」と略記されている。なお、誤解のおそれはないので、図10とその説明においては、例えば仮想CPUコアを単に「CPUの第1コア」などと表記している。
【0373】
また、図10では、ハイパーバイザ320が仮想ハードウェア要素を仮想マシンに対して提供することが「○」印により表されている。逆に、ハイパーバイザ320が仮想ハードウェア要素を仮想マシンに対して提供しないことは、「×」印により表されている。
【0374】
例えば、割り当てルール701は仮想マシン350a用のルールであり、割り当てルール702は仮想マシン350b用のルールである。
【0375】
割り当てルール701によれば、電池残量が30Wh以上のとき、ハイパーバイザ320は、仮想マシン350aに以下の(28a)〜(28f)の仮想ハードウェア要素をすべて提供する。
【0376】
(28a)CPUの第1〜第2コア
(28b)GPUの第1〜第4コア
(28c)USBコントローラ
(28d)WiFiモジュール
(28e)「その他」に分類される仮想ハードウェア要素
(28f)メモリ
【0377】
また、割り当てルール701によれば、電池残量が10Wh以上30Wh未満のとき、ハイパーバイザ320は、仮想マシン350aに以下の(29a)〜(29e)の仮想ハードウェア要素を提供するが、USBコントローラは提供しない。
【0378】
(29a)CPUの第1〜第2コア
(29b)GPUの第1〜第4コア
(29c)WiFiモジュール
(29d)「その他」に分類される仮想ハードウェア要素
(29e)メモリ
【0379】
そして、割り当てルール701によれば、電池残量が1Wh以上10Wh未満のとき、ハイパーバイザ320は、仮想マシン350aに以下の(30a)〜(30d)の仮想ハードウェア要素を提供する。
【0380】
(30a)CPUの第1コア
(30b)GPUの第1〜第2コア
(30c)「その他」に分類される仮想ハードウェア要素
(30d)メモリ
【0381】
しかし、電池残量が1Wh以上10Wh未満のとき、ハイパーバイザ320は、仮想マシン350aに以下の(31a)〜(31d)の仮想ハードウェア要素を提供しない。
【0382】
(31a)CPUの第2コア
(31b)GPUの第3〜第4コア
(31c)USBコントローラ
(31d)WiFiモジュール
【0383】
また、電池残量が1Wh未満のとき、割り当てルール701によれば、ハイパーバイザ320は、仮想マシン350aにCPUの第1コアとメモリを提供するが、残りのいかなる仮想ハードウェア要素も提供しない。
【0384】
ところで、割り当てルール702によれば、電池残量が30Wh以上のとき、ハイパーバイザ320は、仮想マシン350bに以下の(32a)〜(32f)の仮想ハードウェア要素をすべて提供する。
【0385】
(32a)CPUの第1〜第2コア
(32b)GPUの第1〜第4コア
(32c)USBコントローラ
(32d)WiFiモジュール
(32e)「その他」に分類される仮想ハードウェア要素
(32f)メモリ
【0386】
また、割り当てルール702によれば、電池残量が10Wh以上30Wh未満のとき、ハイパーバイザ320は、仮想マシン350bに以下の(33a)〜(33f)の仮想ハードウェア要素を提供するが、CPUの第2コアとGPUの第3〜第4コアは提供しない。
【0387】
(33a)CPUの第1コア
(33b)GPUの第1〜第2コア
(33c)USBコントローラ
(33d)WiFiモジュール
(33e)「その他」に分類される仮想ハードウェア要素
(33f)メモリ
【0388】
そして、割り当てルール702によれば、電池残量が1Wh以上10Wh未満のとき、ハイパーバイザ320は、仮想マシン350bに以下の(34a)〜(34f)の仮想ハードウェア要素を提供するが、CPUの第2コアとGPUの第2〜第4コアは提供しない。
【0389】
(34a)CPUの第1コア
(34b)GPUの第1コア
(34c)USBコントローラ
(34d)WiFiモジュール
(34e)「その他」に分類される仮想ハードウェア要素
(34f)メモリ
【0390】
また、電池残量が1Wh未満のとき、割り当てルール702によれば、ハイパーバイザ320は、仮想マシン350bにCPUの第1コアとメモリを提供するが、残りのいかなる仮想ハードウェア要素も提供しない。
【0391】
割り当てルール701と702を比較すると、以下の2つのことが分かる。
第1に、OS351aと351bに通知される電池残量値(第3実施形態では仮想残量値、第4〜第5実施形態では物理残量値)が同じ場合、CPUコアやGPUコアなどの仮想プロセッサ資源は、仮想マシン350aの方により多く割り当てられる傾向がある。つまり、仮想マシン350aは仮想マシン350bよりも、仮想プロセッサ資源に関して優先されている。
【0392】
第2に、OS351aと351bに通知される電池残量値が同じ場合、仮想プロセッサ資源以外の仮想ハードウェア資源(具体的にはUSBコントローラとWiFiモジュール)は、逆に、仮想マシン350bの方により多く割り当てられる傾向がある。つまり、仮想マシン350bは仮想マシン350aよりも、USBコントローラとWiFiモジュールといった仮想ハードウェア資源に関して優先されている。
【0393】
以上のように、仮想ハードウェア要素の種類に応じて、優先される仮想マシンが異なっていてもよい。もちろん、「電池残量値が同じ場合で比較すれば、仮想ハードウェア要素の種類によらず、ある仮想マシンが他の仮想マシンよりも優先される」となるように、割り当てルールが決められていてもよい。
【0394】
また、図10の例では、割り当てルール701と702で、電池残量に関して同じ「30Wh以上」・「10Wh以上30Wh未満」・「1Wh以上10Wh未満」・「1Wh未満」という条件が使われている。しかし、割り当てルール701と702で電池残量に関する異なる条件が使われてもよい。
【0395】
さて次に、第3実施形態でハイパーバイザ320が行う処理ついて、図11のフローチャートを参照して説明する。ハイパーバイザ320は、例えば仮想マシン350aと350bを動作させるための初期化などの処理を終えた後、図11の処理を開始してもよい。ハイパーバイザ320は、他の処理(例えばハイパーバイザコールへの応答など)と並行して、図11の処理を実行する。
【0396】
ステップS201でハイパーバイザ320は、インデックス変数kに1を代入することで、インデックス変数kを初期化する。
【0397】
次に、ステップS202でハイパーバイザ320は、仮想電池ドライバ340の計算部343から、k番目のOSに関して計算部343が計算した最新の仮想残量値rを取得する。なお、第3実施形態の計算部343は、ハイパーバイザ320からの要求に備えて、計算した仮想残量値rを例えばメモリ211に記憶しておく。
【0398】
次に、ステップS203でハイパーバイザ320は、ハイパーバイザ320がk番目の仮想マシンに提供する仮想ハードウェアの構成を、仮想残量値rと割り当てルールにしたがって決定する。そして、ハイパーバイザ320は、決定にしたがって、必要に応じてk番目の仮想マシンの仮想ハードウェアの構成を変更する。
【0399】
例えば、k番目の仮想マシンが仮想マシン350aであり、仮想残量値rが15Whである場合、ハイパーバイザ320は、仮想マシン350a用の割り当てルール701を参照する。10≦15<30なので、ハイパーバイザ320は、仮想マシン350aに以下の(35a)〜(35e)の仮想ハードウェア要素を提供することに決定するとともに、仮想マシン350aにUSBコントローラを提供しないことに決定する。
【0400】
(35a)CPUの第1〜第2コア
(35b)GPUの第1〜第4コア
(35c)WiFiモジュール
(35d)「その他」に分類される仮想ハードウェア要素
(35e)メモリ
【0401】
そして、ハイパーバイザ320は、上記決定にしたがって、仮想マシン350aに提供する仮想ハードウェアの構成を必要に応じて変更する。
【0402】
例えば、現在ハイパーバイザ320が仮想マシン350aに提供している仮想ハードウェアの構成が、上記で決定した構成と同じ場合があり得る。この場合、ハイパーバイザ320は仮想ハードウェアの構成を変えない。
【0403】
また、上記のようにしてハイパーバイザ320が仮想マシン350aに提供することに決定した仮想ハードウェア要素の中に、現在ハイパーバイザ320が仮想マシン350aに提供していないものがある場合もあり得る。
【0404】
この場合、ハイパーバイザ320は、当該仮想ハードウェア要素のホットアドを行う。すなわち、ハイパーバイザ320は、当該仮想ハードウェア要素を仮想マシン350aに提供し始める。例えば、電池311の充電が進行中のときなどに、以上のようなホットアドが行われる可能性がある。
【0405】
例えば、以下の(36a)と(36b)の2つの条件がともに成り立つ場合、ハイパーバイザ320は、GPUの第3コアのホットアドを行う。
【0406】
(36a)ハイパーバイザ320は、現在はGPUの第3コアを仮想マシン350aに提供していない。
(36b)ハイパーバイザ320は、上記のように割り当てルール701にしたがって、GPUの第3コアを仮想マシン350aに提供することに決定した。
【0407】
逆に、上記のようにしてハイパーバイザ320が仮想マシン350aに提供しないことに決定した仮想ハードウェア要素の中に、現在ハイパーバイザ320が仮想マシン350aに提供しているものがある場合もあり得る。
【0408】
この場合、ハイパーバイザ320は、当該仮想ハードウェア要素のホットリムーブを行う。すなわち、ハイパーバイザ320は、当該仮想ハードウェア要素の仮想マシン350aへの提供を停止する。例えば、ユーザが、電池311の充電を行わずにある程度長い時間にわたって情報処理装置300を利用し続けると、以上のようなホットリムーブが行われる可能性がある。
【0409】
例えば、以下の(37a)と(37b)の2つの条件がともに成り立つ場合、ハイパーバイザ320は、USBコントローラのホットリムーブを行う。
【0410】
(37a)ハイパーバイザ320は、現在はUSBコントローラを仮想マシン350aに提供している。
(37b)ハイパーバイザ320は、上記のように割り当てルール701にしたがって、USBコントローラを仮想マシン350aに提供しないことに決定した。
【0411】
なお、仮想ハードウェア要素の種類に応じて、ハイパーバイザ320はホットリムーブにともなう適宜の処理をさらに行うこともある。例えば、ハイパーバイザ320は、仮想CPUコアをホットリムーブする前に、当該仮想CPUコアに割り当てられた物理CPUコア内のレジスタに記憶されているデータを退避してもよい。
【0412】
以上のとおり、ステップS203では、k番目の仮想マシンの現在の仮想ハードウェア構成と、k番目の仮想マシン用の割り当てルールと、仮想残量値rに基づいて、k番目の仮想マシンの仮想ハードウェア構成が、必要に応じて変更される。
【0413】
そして、次のステップS204でハイパーバイザ320は、インデックス変数kの値と、情報処理装置300内の仮想マシンの数Nを比較する。
【0414】
もし、k<Nであれば、仮想ハードウェア構成を変更するか否かをまだ決めていない仮想マシンが残っている。そこで、図11の処理はステップS204からステップS205へと移行する。
【0415】
逆に、k≧Nであれば(具体的にはk=Nであれば)、すべての仮想マシンの仮想ハードウェア構成が決定済みである。そこで、図11の処理はステップS204からステップS206へと移行する。
【0416】
ステップS205でハイパーバイザ320は、インデックス変数kを1だけインクリメントする。そして、図11の処理はステップS202へと戻る。
【0417】
他方、ステップS206でハイパーバイザ320は、所定の時間が経過するまで待つ。そして、所定の時間が経過すると、図11の処理はステップS201へと戻る。なお、所定の時間の長さは任意だが、所定の時間は、図6〜7のステップS102における単位時間以上であることが好ましい。
【0418】
以上、図11を参照して説明したとおり、第3実施形態では、ハイパーバイザ320が各仮想マシンに関して仮想残量値を定期的に監視し、当該仮想マシンにハイパーバイザ320が提供する仮想ハードウェアの構成を、仮想残量値に応じて動的に変更する。したがって、仮に各仮想マシン上の各OSが省電力制御を行わないとしても、第3実施形態によれば、ホットリムーブの結果として、消費電力量が低減される。その結果、情報処理装置300全体としては、電池311が一層長持ちする。
【0419】
また、仮想マシンの用途に応じた割り当てルールの利用により、情報処理装置300全体としてはバランスのよい電力使用が実現される。例えば、プロセッサ資源を多く使う用途に使われる仮想マシンと、通信資源を多く使う用途に使われる仮想マシンに異なる割り当てルールが適用されてもよい。仮想マシンの用途に応じた割り当てルールの適用により、各仮想マシンからは、当該仮想マシンにとって優先度の低い仮想ハードウェア要素ほど先に削除されることになる。つまり、利便性の維持と節電効果のバランスをとるために、仮想マシンの用途に応じた割り当てルールを用いられてもよい。
【0420】
続いて、第4〜第5実施形態でハイパーバイザ320が行う処理について、図12のフローチャートを参照して説明する。
【0421】
ステップS301でハイパーバイザ320は、電池I/F203から物理残量値Rを取得する。
【0422】
次にステップS302でハイパーバイザ320は、インデックス変数kに1を代入することで、インデックス変数kを初期化する。
【0423】
次に、ステップS303でハイパーバイザ320は、ハイパーバイザ320がk番目の仮想マシンに提供する仮想ハードウェアの構成を、物理残量値Rと割り当てルールにしたがって決定する。そして、ハイパーバイザ320は、決定にしたがって、必要に応じてk番目の仮想マシンの仮想ハードウェアの構成を変更する。なお、ステップS303は、決定に際して仮想残量値rではなく物理残量値Rが使われる点以外は、図11のステップS203と同様である。よって、詳しい説明は省略する。
【0424】
次のステップS304でハイパーバイザ320は、インデックス変数kの値と、情報処理装置300内の仮想マシンの数Nを比較する。
【0425】
もし、k<Nであれば、仮想ハードウェア構成を変更するか否かをまだ決めていない仮想マシンが残っている。そこで、図12の処理はステップS304からステップS305へと移行する。
【0426】
逆に、k≧Nであれば(具体的にはk=Nであれば)、すべての仮想マシンの仮想ハードウェア構成が決定済みである。そこで、図12の処理はステップS304からステップS306へと移行する。
【0427】
ステップS305でハイパーバイザ320は、インデックス変数kを1だけインクリメントする。そして、図12の処理はステップS303へと戻る。
【0428】
他方、ステップS306でハイパーバイザ320は、所定の時間が経過するまで待つ。そして、所定の時間が経過すると、図12の処理はステップS301へと戻る。なお、所定の時間の長さは任意だが、所定の時間は、図6〜7のステップS102における単位時間以上であることが好ましい。
【0429】
以上、図12を参照して説明したとおり、第4〜第5実施形態では、ハイパーバイザ320が電池311の物理的な残量を定期的に監視し、各仮想マシンにハイパーバイザ320が提供する仮想ハードウェアの構成を、電池311の物理的な残量に応じて動的に変更する。したがって、仮に各仮想マシン上の各OSが省電力制御を行わないとしても、第4〜第5実施形態によれば、ホットリムーブの結果として、消費電力量が低減される。その結果、情報処理装置300全体としては、電池311が一層長持ちする。
【0430】
また、第5実施形態では仮想残量値が使われないが、第5実施形態においても、「ハイパーバイザ上で複数のOSが動作する場合にも、情報処理装置全体として適切に電力が使用される」という効果が得られる。具体的には、仮想マシンの用途に応じた割り当てルールの利用により、当該効果が得られる。なぜなら、第3実施形態に関して説明した「仮想マシンの用途に応じた割り当てルールの利用により、利便性の維持と節電効果のバランスがとれる」という効果は、第4実施形態および第5実施形態でも同様だからである。
【0431】
さて、図13は、仮想ハードウェアの動的な構成変更の効果を説明する図である。具体的には、図13には、ハイパーバイザ320が仮想ハードウェアの構成を動的に変更することのない第4比較例についての計算例801と、第5実施形態についての計算例802が例示されている。
【0432】
以下では説明の簡単化のため、図2のCPU204とGPU205とWiFiモジュール216による消費電力量の和により、情報処理装置200全体の消費電力量が近似されるものとする。
【0433】
また、説明の簡単化のため、OS351aと351bが何も省電力制御を行わないと仮定する。換言すれば、OS351aと351bは、いずれも、次の(38a)〜(38c)のようなルールセットにしたがうものとする。
【0434】
(38a)電池の残量によらず、すべてのCPUコアを、CPUコアに設定可能な最大周波数(説明の便宜上1GHzとする)で動作させる。
(38b)電池の残量によらず、すべてのGPUコアを稼働させておく。
(38c)電池の残量によらず、WiFiモジュールを介した通信の量は無制限である。
【0435】
また、説明の簡単化のため、情報処理装置300にはデュアルコアの物理CPUとクアッドコアの物理GPUがあるとする。
【0436】
そして、仮想マシン350a用の仮想CPUの第1コアと仮想マシン350b用の仮想CPUの第1コアには、物理CPUの第1コアが割り当て可能だとする。同様に、仮想マシン350a用の仮想CPUの第2コアと仮想マシン350b用の仮想CPUの第2コアには、物理CPUの第2コアが割り当て可能だとする。
【0437】
GPUについても同様に、仮想マシン350a用の仮想GPUの第mコアと仮想マシン350b用の仮想GPUの第mコアには、物理CPUの第mコアが割り当て可能だとする(m=1〜4)。
【0438】
さらに、各物理CPUコアが1GHzで動作するための電力は、1Wであるものとする。また、各物理GPUコアが動作するための電力は、2Wであるものとする。そして、或る期間に物理CPUコアによって消費される電力量は、当該期間における物理CPUコアの使用率に比例するものとする。
【0439】
さて、図13における記号「t」と「R」と「c」と「c」は、図8〜9と同様である。また、図13では、仮想ハードウェア要素がホットリムーブされるタイミングを、太い横罫線により示している。
【0440】
図13の計算例801と802それぞれのテーブルにおいて、時刻tの行の「u」は、時刻tから時刻(t+1)までの単位時間の間における、仮想マシン350aの動作に起因する物理CPUコアの使用率を示す。説明の簡単化のため、仮想マシン350a用の仮想CPUコアに割り当てられているどの物理CPUコアの使用率も、同じ率uであるものとする。
【0441】
同様に、時刻tの行の「u」は、時刻tから時刻(t+1)までの単位時間の間における、仮想マシン350bの動作に起因する物理CPUコアの使用率を示す。説明の簡単化のため、仮想マシン350b用の仮想CPUコアに割り当てられているどの物理CPUコアの使用率も、同じ率uであるものとする。
【0442】
ところで、時刻tの行の「w」は、仮想マシン350aの仮想WiFiモジュールを介して行われる通信の、時刻tから時刻(t+1)までの期間における平均データレートを示す。同様に、時刻tの行の「w」は、仮想マシン350bの仮想WiFiモジュールを介して行われる通信の、時刻tから時刻(t+1)までの期間における平均データレートを示す。データレートwとwの単位はいずれも[kB/h]である。
【0443】
仮想マシン350aから仮想WiFiモジュールがホットリムーブされた場合は、当然w=0である。同様に、仮想マシン350bから仮想WiFiモジュールがホットリムーブされた場合は、w=0である。
【0444】
さて、説明の便宜上、時刻tにおいてハイパーバイザ320が仮想マシン350aに提供している仮想CPUコアの数を「n」とする。また、時刻tにおいてハイパーバイザ320が仮想マシン350aに提供している仮想GPUコアの数を「m」とする。
【0445】
同様に、時刻tにおいてハイパーバイザ320が仮想マシン350bに提供している仮想CPUコアの数を「n」とする。また、時刻tにおいてハイパーバイザ320が仮想マシン350bに提供している仮想GPUコアの数を「m」とする。
【0446】
すると、以上説明した仮定より、電力cとcは、式(10)と(11)のように表すことができる。
【数10】
【数11】
【0447】
また、時刻tから時刻(t+1)までの単位時間における消費電力量は、「(c+c)×1」と表すことができる。計算例801および802それぞれにおいて、時刻(t+1)における物理残量値Rは、時刻tにおける物理残量値Rから、この「(c+c)×1」という消費電力量を引いた値である。
【0448】
式(10)によれば、例えば計算例801の各行に示すように、u=50かつw=65かつn=2かつm=4の場合は、c=9.65である。また、式(11)によれば、計算例801の各行に示すように、u=25かつw=100かつn=2かつm=4の場合は、c=9.5である。
【0449】
計算例801は、上記のとおり、ハイパーバイザ320がホットリムーブを行わない第4比較例についての例である。よって、計算例801では、物理残量値Rが減少しても、物理残量値Rが大きかったときと同様に大きな電力が使われてしまう。そのため、計算例801では、時刻t=6のときには既に電池切れになっている。
【0450】
他方、第5実施形態による計算例802では、時刻t=6ではまだ電池切れになっておらず、電池311がより長持ちしている。具体的には、第5実施形態では、物理残量値Rの減少に応じて、仮想マシン350aから仮想ハードウェア要素が動的に削除され、仮想マシン350bからも仮想ハードウェア要素が動的に削除される。そのため、動的に削除される仮想ハードウェア要素に割り当てられていた物理ハードウェア要素の消費電力量の分、第5実施形態では情報処理装置300の消費電力量が第4比較例よりも少ない。その結果として、図13に示すように、電池311が長持ちする。
【0451】
例えば、物理残量値Rが10Wh以上の場合(具体的には、計算例802のt=0からt=4の行においては)、割り当てルール701よりn=2かつm=4である。よって、この場合、計算例802に示した使用率uとデータレートwによれば、c=9.65である。
【0452】
しかし、物理残量値Rが1Wh以上10Wh未満の場合(具体的には、計算例802のt=5の行においては)、割り当てルール701よりn=1かつm=2かつw=0である。よって、この場合、計算例802に示した使用率uによれば、c=4.5である。
【0453】
また、物理残量値Rが1Wh未満の場合(具体的には、計算例802のt=6の行においては)、割り当てルール701よりn=1かつm=0かつw=0である。よって、この場合、計算例802に示した使用率uによれば、c=0.5である。
【0454】
以上のように、物理残量値Rの減少に応じて、仮想マシン350aから仮想ハードウェア要素が動的に削除され、仮想マシン350aの実行にかかる電力が抑えられる。仮想マシン350bに関しても同様である。
【0455】
例えば、物理残量値Rが30Wh以上の場合(具体的には、計算例802のt=0からt=3の行においては)、割り当てルール702よりn=2かつm=4である。よって、この場合、計算例802に示した使用率uとデータレートwによれば、c=9.5である。
【0456】
また、物理残量値Rが10Wh以上30Wh未満の場合(具体的には、計算例802のt=4の行においては)、割り当てルール702よりn=1かつm=2である。よって、この場合、計算例802に示した使用率uとデータレートwによれば、c=5.25である。
【0457】
そして、物理残量値Rが1Wh以上10Wh未満の場合(具体的には、計算例802のt=5の行においては)、割り当てルール702よりn=1かつm=1である。よって、この場合、計算例802に示した使用率uとデータレートwによれば、c=3.25である。
【0458】
また、物理残量値Rが1Wh未満の場合(具体的には、計算例802のt=6の行においては)、割り当てルール702よりn=1かつm=0かつw=0である。よって、この場合、計算例802に示した使用率uによれば、c=0.25である。
【0459】
以上、図13を参照して説明したように、たとえOSが省電力制御を行わなくても、第5実施形態では、電池311が長持ちし、情報処理装置300の可用時間が第4比較例よりも長い。また、第4実施形態では、第5実施形態と同様のホットリムーブによる節電効果に加えて、さらに、OSが行う省電力制御による節電効果も得られる。そして、第3実施形態では、第4実施形態と同様の節電効果に加えて、例えば次の(39a)〜(39b)のような効果も得られる。
【0460】
(39a)物理残量値の代わりに仮想残量値を用いてOSが省電力制御を行うことによる、情報処理装置300全体としての適切な電力配分。
(39b)適切な電力配分の結果としての更なる節電効果。
【0461】
なお、本発明は上記の第1〜第5実施形態に限られるものではなく、上記実施形態は様々に変形可能である。以下に、上記実施形態を変形するいくつかの観点を例示する。例えば、上記実施形態は、下記のいくつかの観点から様々に変形することもでき、これらの変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。
【0462】
図6のステップS108では、物理残量値Rが閾値Dp未満か否かが判断される。しかし、実施形態によっては、物理残量値Rが閾値Dp以下か否かが判断されてもよい。また、図7のステップS117では仮想残量値rが閾値Dv未満か否かが判断される。しかし、実施形態によっては、仮想残量値rが閾値Dv以下か否かが判断されてもよい。
【0463】
また、各閾値の具体的な値は、実施形態に応じて適宜任意に決められてよい。図4、5、8〜10、13に例示した様々な数値も、説明の便宜上の例示的な値に過ぎない。
【0464】
図4と5には、便宜上、テーブル形式で様々なデータを例示した。しかし、データ形式は実施形態に応じて任意である。例えば、使用状況情報344は、リングバッファに記憶されてもよい。また、線形リスト、連想配列、CSV(Comma Separated Values)などのデータ形式も利用可能である。実施形態によっては、ルールセット500、520、および540は、所定のマークアップ言語にしたがって記述されていてもよい。
【0465】
また、図10の割り当てルール701と702も、実施形態に応じて適宜のデータ形式で表現されていてよい。
【0466】
第2実施形態では、OSごとにモード情報346が定義されているが、全OSのモードが同じでもよい。全OSのモードが同じ場合、モード情報346は省略されてもよい。
【0467】
もちろん、全OSのモードが同じ場合でも、モード情報346があってもよい。例えば、3つのモードが選択可能な場合、ユーザからの入力にしたがって、3つのモードのうちの1つを示す値が、モード情報346として不揮発性記憶装置212に記憶されてもよい。この場合、モード情報346は、全OSに共通のモードを示す。つまり、モード情報346は、OSごとの特性を表す特性情報ではなく、計算部343による計算の方法を指定するための情報として使われてもよい。
【0468】
なお、選択可能なモードの数は、第2実施形態のように3でもよいし、2でもよいし、4以上であってもよい。例えば、第2実施形態に関して説明した第1〜第3モードのうち2つだけが選択可能な実施形態も可能である。
【0469】
逆に、第4モードが定義されている実施形態も可能である。例えば、第4モードは、「電池311が充電中の場合、ステップS107で取得された物理残量値RとステップS116で計算された仮想残量値rに基づいて、計算部343が、仮想残量値rを計算しなおす」というモードであってもよい。例えば、計算部343は、物理残量値Rと仮に計算された仮想残量値rとの最大値、最小値、平均値、または重み付け和を、最終的な仮想残量値rとして計算してもよい。
【0470】
第2実施形態では、計算部343による計算の方法は、モード情報346とフラグ347に応じて可変である。しかし、上記のとおり実施形態によってはモード情報346が省略可能なのと同様に、フラグ347も実施形態によっては省略可能である。例えば、フラグ347が省略される場合、図6のステップS113〜S114が省略されてもよい。あるいは、フラグ347が省略される場合、図6のステップS113では電池311が充電中か否かだけが判断されてもよく、電池311が充電中のときにステップS114が実行されてもよい。
【0471】
また、図6のステップS108〜S112に示すように、物理残量値Rが閾値Dp未満のときに各OSにゼロという仮想残量値が通知されるならば、図7のステップS117〜S118は省略されてもよい。ステップS117〜S118が省略される場合、ステップS116の計算の実行後、処理はステップS119に移行する。
【0472】
実施形態によっては逆に、図6のステップS108〜S112が省略されてもよい。具体的には、図7のステップS117〜S118のように仮想残量値rが閾値Dv未満のときにゼロという仮想残量値が通知されるならば、ステップS108〜S112が省略されてもよい。ステップS108〜S112が省略される場合、ステップS107での物理残量値Rの取得の後、処理はステップS113に移行する。
【0473】
なお、図6〜7のフローチャートに示したステップの実行順序は、矛盾が生じない限り適宜入れ替えられてもよい。
【0474】
第2実施形態では、プロファイラ341aおよび341b、取得部342、ならびに計算部343が仮想電池ドライバ340内に実装されている。しかし、実施形態によっては、プロファイラ341aおよび341b、取得部342、ならびに計算部343の一部または全部が、ハイパーバイザ320内に実装されていてもよい。
【0475】
また、第2実施形態では、OS351aに対応してプロファイラ341aが設けられており、OS351bに対応してプロファイラ341bが設けられている。しかし、実施形態によっては、1つのプロファイラのみが設けられていてもよく、1つのプロファイラが各OSについての使用状況情報344を生成するとともに、各OSへ仮想残量値を通知してもよい。
【0476】
第2実施形態では1つの計算部343が各OSの仮想残量値を計算するが、実施形態によっては、OSごとに別の計算部が設けられていてもよい。その場合、複数の計算部の各々は、当該計算部に対応するOSの仮想残量値のみを計算してもよい。
【0477】
第2実施形態のプロファイラ341aは、図1の第1の取得部105と類似の動作をするだけでなく、通知部104と類似の動作をする。しかし、実施形態によっては、プロファイラ341aが、第1の取得部105と類似の動作をするコンポーネントと、通知部104と類似の動作をするコンポーネントに、分割されてもよい。プロファイラ341bも同様に、分割されてもよい。
【0478】
計算部343が使用状況情報344を使わずに仮想残量値を計算する場合、使用状況情報344は省略可能である。この場合、プロファイラ341aと341bが使用状況情報344を生成する必要もない。また、この場合、図6のステップS103〜S106も省略可能である。
【0479】
ところで、第3〜第5実施形態の共通点は、「どの仮想マシンについても仮想残量値に基づく制御が行われるか、または、どの仮想マシンについても物理残量値に基づく制御が行われる」という点である。しかし、仮想マシンごとに、「当該仮想マシンの仮想ハードウェアの構成をハイパーバイザが仮想残量値と物理残量値のいずれに応じて変更するのか」ということが決められていてもよい。例えば、ハイパーバイザ320は、仮想マシン350aの仮想ハードウェア構成を、仮想マシン350aに対応する仮想残量値rに基づいて変更する一方で、仮想マシン350bの仮想ハードウェア構成を、物理残量値Rに基づいて変更してもよい。また、動的に仮想ハードウェア構成を変更しないことに決められている仮想マシンがあってもよい。
【符号の説明】
【0480】
100、200、300 情報処理装置
101、201、311 電池
102a、102b、351a、351b OS
103 評価部
104 通知部
105 第1の取得部
106 第2の取得部
202 バス・インタコネクト
203 電池I/F
204 CPU
205 GPU
206 タッチパネル
207 LCD I/F
208 タッチパネルI/F
209 カメラ
210 カメラI/F
211 メモリ
212 不揮発性記憶装置
213、217 RF回路
214 無線I/F
215 USBコントローラ
216 WiFiモジュール
218 NFC I/F
310 ハードウェア
320 ハイパーバイザ
330 仮想ドライバ
340 仮想電池ドライバ
341a、341b プロファイラ
342 取得部
343 計算部
344 使用状況情報
345 優先度情報
346 モード情報
347 フラグ
350a、350b 仮想マシン
352a、352b アプリケーション
401a、401b プロファイル
500、520、540 ルールセット
501〜503、521〜523、541〜543 条件
504〜510、524〜530、544〜548 ルール
601〜605、801、802 計算例
701、702 割り当てルール
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13

【手続補正書】
【提出日】2014年10月27日
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
電池で駆動される情報処理装置であって、
前記情報処理装置上で動作するハイパーバイザ上で動作する複数のオペレーティング・システムそれぞれの特性を示す特性情報と、前記電池の物理的な残量を示す物理残量値とを用いて、前記複数のオペレーティング・システムそれぞれに対応する、前記電池の仮想的な残量を評価する評価部と、
前記複数のオペレーティング・システムそれぞれに、当該オペレーティング・システムに対応して前記評価部が評価した値である仮想残量値を通知する通知部と
を備えることを特徴とする情報処理装置。
【請求項2】
前記複数のオペレーティング・システムそれぞれの前記特性情報が、
当該オペレーティング・システムおよび当該オペレーティング・システム上で動作するアプリケーションにより使用された資源の量を示す使用状況情報と、
当該オペレーティング・システムの優先度を示す優先度情報
のうち少なくとも一方を含むことを特徴とする請求項1に記載の情報処理装置。
【請求項3】
前記特性情報が、複数の期間のそれぞれと対応づけられた前記使用状況情報を含む
ことを特徴とする請求項2に記載の情報処理装置。
【請求項4】
前記電池が充電中のとき、前記評価部は、前記複数のオペレーティング・システムのうち少なくとも1つ以上のそれぞれに対して、前記仮想残量値を、
当該オペレーティング・システムに対応する前記仮想残量値の定義域の最大値、または
前記物理残量値の定義域の最大値
と見なすことを特徴とする請求項1から3のいずれか1項に記載の情報処理装置。
【請求項5】
前記電池が充電中のとき、前記評価部は、
前記物理残量値が、前記物理残量値の定義域の最大値であると見なし、
前記最大値と見なした前記物理残量値を用いて、前記複数のオペレーティング・システムそれぞれに対応する前記仮想残量値を評価する
ことを特徴とする請求項1から3のいずれか1項に記載の情報処理装置。
【請求項6】
前記電池が充電中のとき、前記評価部は、前記複数のオペレーティング・システムのうち少なくとも1つ以上のそれぞれに対応する前記仮想残量値を、前記物理残量値と同じと見なす
ことを特徴とする請求項1から3のいずれか1項に記載の情報処理装置。
【請求項7】
前記複数のオペレーティング・システムのそれぞれが動作する、前記ハイパーバイザ上の各仮想マシンに、前記ハイパーバイザが提供する仮想ハードウェアの構成を、前記ハイパーバイザが、
前記物理残量値、または
当該仮想マシン上の当該オペレーティング・システムに対応する前記仮想残量値
に応じて変更する
ことを特徴とする請求項1から6のいずれか1項に記載の情報処理装置。
【請求項8】
電池で駆動される情報処理装置が実行する電池残量通知方法であって、
前記情報処理装置上で動作するハイパーバイザ上で動作する複数のオペレーティング・システムそれぞれの特性を示す特性情報と、前記電池の物理的な残量を示す物理残量値とを用いて、前記複数のオペレーティング・システムそれぞれに対応する、前記電池の仮想的な残量を評価し、
前記複数のオペレーティング・システムそれぞれに、当該オペレーティング・システムに対応して前記電池の前記仮想的な残量を評価した値である仮想残量値を通知する
ことを特徴とする電池残量通知方法。
【請求項9】
電池で駆動される情報処理装置に、
前記情報処理装置上で動作するハイパーバイザ上で動作する複数のオペレーティング・システムそれぞれの特性を示す特性情報と、前記電池の物理的な残量を示す物理残量値とを用いて、前記複数のオペレーティング・システムそれぞれに対応する、前記電池の仮想的な残量を評価し、
前記複数のオペレーティング・システムそれぞれに、当該オペレーティング・システムに対応して前記電池の前記仮想的な残量を評価した値である仮想残量値を通知する
ことを含む処理を実行させる電池残量通知プログラム。
【請求項10】
前記ハイパーバイザ上で動作する、前記電池のデバイスドライバのプログラムに含まれることを特徴とする請求項9に記載の電池残量通知プログラム。
【国際調査報告】