JP2008269094A - 情報処理装置、情報処理装置の最適化方法、プログラム - Google Patents

情報処理装置、情報処理装置の最適化方法、プログラム Download PDF

Info

Publication number
JP2008269094A
JP2008269094A JP2007108531A JP2007108531A JP2008269094A JP 2008269094 A JP2008269094 A JP 2008269094A JP 2007108531 A JP2007108531 A JP 2007108531A JP 2007108531 A JP2007108531 A JP 2007108531A JP 2008269094 A JP2008269094 A JP 2008269094A
Authority
JP
Japan
Prior art keywords
optimization
status information
usage status
operating system
software
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2007108531A
Other languages
English (en)
Inventor
Yasutoshi Ota
泰稔 太田
Hideaki Shimizu
秀晃 清水
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toyota Motor Corp
Original Assignee
Toyota Motor Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toyota Motor Corp filed Critical Toyota Motor Corp
Priority to JP2007108531A priority Critical patent/JP2008269094A/ja
Publication of JP2008269094A publication Critical patent/JP2008269094A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Stored Programmes (AREA)

Abstract

【課題】ユーザの利用状況に応じてソフトウェアを最適化する情報処理装置、情報処理装置の最適化方法及びプログラムを提供すること。
【解決手段】複数のOS1,OS2が独立に動作可能な情報処理装置10において、第2のオペレーティングシステムで実行されるソフトウェア2の利用状況情報32を記憶した利用状況情報記憶手段14と、利用状況情報32を参照する、第1のオペレーティングシステムで実行される利用状況情報参照手段22と、利用状況情報32に基づき第2のオペレーティングシステムを最適化する、第1のオペレーティングシステムで実行されるOS最適化手段23と、を有することを特徴とする。
【選択図】図3

Description

本発明は、ソフトウェアの最適化が可能な情報処理装置等に関し、特に、利用状況に応じてソフトウェアを最適化する情報処理装置、情報処理装置の最適化方法及びプログラムに関する。
アプリケーションプログラムは限られた範囲のプラットフォーム上で動作する一方、多様なユーザニーズに対応するため、1つのプラットフォームでアプリケーションプログラムを含め多くのソフトウェア的な機能が実行可能となっている。プラットフォームは、ユーザの操作や利用されるハードウェアに応じて適切なソフトウェアを起動しその機能を提供するが、多くの場合、実行可能なソフトウェア又はその機能の全てが使用されることはない。そこで、アプリケーションプログラムに応じてコンピュータが最適化されるよう、1つのプラットフォームにおいて単一の命令セットでなく多数の命令セットを付加できる再構成可能なコンピュータが提案されている(例えば、特許文献1参照。)。特許文献1記載のコンピュータでは、アプリケーションプログラムを処理するコンピュータの能力を最適化するプログラマブルロジックによりコンピュータを再構成することができる。
特表2002−530780号公報
しかしながら、特許文献1記載のコンピュータは、プログラマブルロジックがメモリやCPUへの入出力回路を再構成するものであって、ソフトウェアの再構成については考慮されていない。アプリケーションプログラムを実際に実行した場合にはメモリやCPUの資源を再構成できるが、この再構成はハードウェアの拡張に等しいものであって、ユーザの利用状況に応じてソフトウェア資源までを最適化したものではない。このため、例えば、利用頻度の高いソフトウェアの処理効率を向上させたり、低いソフトウェアの優先度を下げるなどのソフトウェア面の配慮がなく、コンピュータの最適化としては不十分である。
本発明は、上記課題に鑑み、ユーザの利用状況に応じてソフトウェアを最適化する情報処理装置、情報処理装置の最適化方法及びプログラムを提供することを目的とする。
上記課題に鑑み、本発明は、複数のOSが独立に動作可能な情報処理装置において、第2のオペレーティングシステムで実行されるソフトウェアの利用状況情報を記憶した利用状況情報記憶手段と、利用状況情報を参照する、第1のオペレーティングシステムで実行される利用状況情報参照手段と、利用状況情報に基づき第2のオペレーティングシステムを最適化する、第1のオペレーティングシステムで実行されるOS最適化手段と、を有することを特徴とする。
本発明によれば、第1のOSが利用状況情報を参照して第2のOSを最適化するので、利用頻度やソフトウェアの特性に応じてOSレベルで互いにOSを最適化することができる。
また、本発明によれば、複数のOSが独立に動作可能な情報処理装置において、第2のオペレーティングシステムで実行されるソフトウェアの利用状況情報を記憶した利用状況情報記憶手段と、第1のオペレーティングシステムに最適化を要求する、第2のオペレーティングシステムで実行される最適化要求手段と、第2のオペレーティングシステムを最適化する、第1のオペレーティングシステムで実行されるOS最適化手段と、を有することを特徴とする。
本発明によれば、第2のOSが利用状況情報を参照して第1のOSに最適化要求するので、タイミングよく、利用頻度やソフトウェアの特性に応じてOSレベルで互いにOSを最適化することができる。
また、本発明の一形態において、OS最適化手段は、利用頻度が所定以下のソフトウェアを停止する、ことを特徴とする。
本発明によれば、利用頻度の低いソフトウェアを停止するので、発熱や消費電力を低減できる。
ユーザの利用状況に応じてソフトウェアを最適化する情報処理装置、情報処理装置の最適化方法及びプログラムを提供することができる。
以下、本発明を実施するための最良の形態について図面を参照しながら説明する。
図1は、情報処理装置10のハードウェア構成図を示す。本実施形態の情報処理装置10は、1台で複数のOSを動作可能としユーザの利用状況に応じて、OSレベルで機能の再構築を行うことで、ユーザのよく利用する機能に資源を割り振ったり、利用されない機能への資源の割り当てを停止するなどして、情報処理装置10を最適化する。
情報処理装置10は、プログラムを実行するCPU11、プログラム実行の作業領域となりまた一時的にデータを記憶するRAM12、ブートプログラムやBIOSを記憶するROM13、プログラムやファイルを記憶するフラッシュメモリやハードディスク装置14、キーボードやマウスなどの入力装置15、DVD(Digital Versatile Disk)等の記憶媒体に情報を読み書きするドライブ装置16、GUIなどユーザインターフェイスをディスプレイに表示する表示制御装置17、がバスにより接続されている。
本実施形態では複数のOS1、OS2を並行に動作するため、特にCPU11は、複数のCPUを備えたマルチCPU又は演算ユニットを複数設けたマルチコア型である。CPU11は、少なくとも2つのOSを同時に互いに独立に動作させ、一方のOSが他方のOSを再構築できるので、互いにOSを停止させることなくOSレベルの最適化が可能となる。
図2は、情報処理装置10の機能ブロック図を示す。情報処理装置10は、ハードウェア(以下、HWという)20として提供されるいくつかの機能H(機能H1、H2、H3…)を有し、HW20上で2つの異なるオペレーティングシステム(以下、OSという)1及びOS2が独立かつ並行に動作する。OS1は、例えばWindows(登録商標)、OS2は、例えばLINUX(登録商標)である。
また、OS1はソフトウェア1としていくつかの機能S(機能1A、1B、1C…)を提供し、OS2はソフトウェア2としていくつかの機能S(機能2A、2B、2C…)を提供する。これらソフトウェア1、ソフトウェア2は、CPU11がオブジェクトコードを実行することで実現され、ソフトウェア1とソフトウェア2が同じ機能であっても、多くの場合ソースプログラムから異なる。
一例を挙げれば、機能1A、2Aはアプリケーションプログラム、機能1B、2Bはライブラリ、機能1C、2Cはデバイスドライバである。また、HW20の機能H1は、例えば、表示制御装置17,機能H2はドライブ装置16、機能H3はハードディスク装置14、等であるが、当然ながらCPU11、RAM12及び入力装置15もHW20に含まれる。
ソフトウェア1の各機能SとHW20の各機能Hは1対1に対応するものではなく、複数のアプリケーションプログラム(例えば、ナビゲーションやメディアプレーヤ(機能1A))が表示制御装置17(機能H1)を共有するし、ほぼ全てのソフトウェア1がハードディスク装置14(機能H3)を共有する。
このような共有は、例えば機能1C、2Cの所定のデバイスドライバ(以下、このデバイスドライバをOS制御ドライバという)により実現される。OS制御ドライバについて簡単に説明する。
電源オンされると、CPU11は、ROM13から起動プログラムやBIOSを読み出し、OS制御ドライバを起動し、ついで、予め定められたOSを自動的に起動する。また、OSに次いで自動的に起動するよう設定されたAPがあれば、予め定めたOS(OS1又はOS2)上で当該APを実行する。
OS制御ドライバは、運転者が存在を意識することのない常駐型のソフトウェアで、OS1、2に対しHW20を論理的(時間的にも)に分割し割り当てる。OS制御ドライバは、この論理分割を利用して複数の仮想的な計算機の実行環境を作り、それらの実行環境の上で複数のOS1、OS2を動作させる。仮想的な実行環境の制御に必要なHW20はOS制御ドライバによりOS1又はOS2から隠蔽されている。OS1又はOS2はシステムコールを発行することで各種のサービスをOS制御ドライバに要求することができる。
OS制御ドライバはOS1,OS2が通信するための手段を備え、例えば、実行環境間の割り込み(イベント発生)、メッセージ送受信、共有メモリ等を提供する。また、OS制御ドライバは、OS1からOS2が使用している物理メモリをアクセス可能としたり、OS2の所定のメモリの内容をOS1にコピーするなど、OS間での情報交換を可能とする。したがって、OS制御ドライバにより、OS1はOS2の次述する利用状況情報を参照し、OS2のソフトウェア2を最適化することができ、OS2はOS1の利用状況情報を参照し、OS1のソフトウェアを最適化することができる。
図3は、OSの最適化の概略を説明する説明図を示す。OS1は、CPU11がプログラムを実行することで実現される利用頻度集計手段21、利用状況情報参照手段22、OS最適化手段23、コンパイル手段24を有し、OS2はCPU11がプログラムを実行することで実現される最適化要求手段25を有する。プログラムは、ハードディスク装置14に記憶されており、各OSが図3の利用頻度集計手段21等を有するが、ここではOS1を対象にして説明する。
利用頻度集計手段21は、自身のOS(図3ではOS1)におけるソフトウェア1の各機能Sの利用頻度を集計する。ソフトウェア1は、例えばアプリケーションプログラム、ライブラリ、デバイスドライバ等であるので、利用頻度集計手段21は、アプリケーションプログラム毎、ライブラリ毎、デバイスドライバ毎に利用頻度を集計する。
車両の乗員が操作してソフトウェア1を利用したり、何らかのHW20を使用して自動的にソフトウェア1が利用されると、利用頻度集計手段21がそれを検知して利用回数をカウントアップする。利用頻度集計手段21は、毎日、ソフトウェア1の利用の有無を記憶しておき、週毎又は月毎の利用頻度を集計する。このような集計により、OS毎にソフトウェアの利用状況情報を記憶しておくことができる。
図4は、利用状況情報の一例を示す図である。利用状況情報は、アプリケーションプログラム、ライブラリ、デバイスドライバ毎にハッシュ値などのIDに対応づけて利用頻度を記憶している。例えば、「11AA」のアプリケーションプログラムは利用頻度が週に2回、月に5回であるが、「12BB」のアプリケーションプログラムは利用頻度が週に0回、月に1回となっている。なお、利用状況情報は、運転者又は乗員などによって異なるものであるので、利用状況情報は運転者毎、乗員の組み合わせ毎、に複数保持することが好適である。
OS1利用状況情報31,OS1ソースコード41、OS1オブジェクトコード51、OS2利用状況情報32,OS2ソースコード42、OS2オブジェクトコード52、はハードディスク装置14に記憶されている。このうち、OS1ソースコード41、OS2ソースコード42については、最適化の際に必要となるので常に車載する必要はなく、サーバからダウンロードしてもよい。
図3に戻り、利用状況情報参照手段22は、他のOS(図3ではOS2)のOS2利用状況情報32を参照してOS最適化手段23に利用状況情報を送出する。利用状況情報の参照は、OS2のソフトウェア2を最適化するためであるので、例えば、週に1回程度実行してもよいし、毎日実行してもよい。
そして、OS最適化手段23は、利用状況情報に基づき最適化するソフトウェア2の機能2A〜2C、すなわち、アプリケーションプログラム、ライブラリ、デバイスドライバを決定する。最適化は、利用頻度が所定以上変動した機能Sや、利用頻度が他の機能Sよりも高い機能S又は低い機能Sを対象に行う。
例えば、OS最適化手段23は、利用頻度の高い順に、アプリケーションプログラムの上位5個、ライブラリの上位5個、デバイスドライバの上位5個というように、OS2にて最適化対象にする機能Sを決定する。また、アプリケーションプログラムはよく使うが、ライブラリはあまり使わないといった利用頻度の場合には、アプリケーションプログラムをライブラリよりも多く最適化対象としてもよい。また、アプリケーションプログラム毎、ライブラリ毎、デバイスドライバ毎に、それぞれ閾値を定めておき、閾値以上の利用頻度の機能Sを最適化対象としてもよい。
また、利用頻度の低い機能Sについては、未使用の機能Sや、資源を開放すべき観点から他の機能Sよりも相対的に利用頻度が下がった機能Sが最適化対象となる。
OS最適化手段23は最適化対象とするソフトウェア2を決定すると、そのソフトウェア2をコンパイル手段24に通知する。コンパイル手段24は、OS2で実行できるオブジェクトコードをOS1上で生成するいわゆるクロスコンパイラである。
また、OS最適化手段23は、最適化対象のソフトウェア2をコンパイル手段24に通知する際、コンパイラオプションを指定する。コンパイラオプションには種々のものがあるが、本実施形態では主に最適化のためのコンパイラオプションを指定する。例えば、
できるだけ小さいオブジェクトコードを生成するコンパイラオプション、できるだけ高速のオブジェクトコードを生成するコンパイラオプション、初期状態で確保するメモリ量を指定するコンパイラオプション、CPU11の特定の命令セットを積極的に利用してオブジェクトコードを生成するコンパイラオプション、等である。このように、コンパイルする時点で、利用頻度に応じて最適なオブジェクトコードを生成することで、OSレベルで情報処理装置10をそのユーザに最適化することができる。
コンパイル手段24は、最適化対象とされたソフトウェア2のソースコードをOS2ソース42から読み出し、指定されたコンパイラオプションによりコンパイルする。OS最適化手段23は、コンパイルにより生成されたオブジェクトコードをOS2オブジェクトコード52に記憶する。したがって、以降OS2は、利用状況情報に基づき最適化されたソフトウェア2を実行することができる。
ところで、OSレベルの更新は最適化対象となったソフトウェアがRAM12等に展開されていないこと(実行されていないこと)が必要であるが、アプリケーションプログラム、ライブラリ、デバイスドライバであれば多くの場合、これらは停止させることができるため、OS2を起動したまま更新することができる。しかしながら、メモリ監視やタイマなどカーネルは常に起動しているため、OS2を起動したまま最適化することが困難である。このため、OS最適化手段23は、最適化対象がカーネルに含まれる機能Sの場合、いったんOS2を終了してカーネルを最適化した後再起動する。したがって、本実施形態の情報処理装置10によれば、OS2のカーネルであっても最適化することができる。
また、最適化するOS1がOS2の利用状況情報を読み出すのでなく、最適化されるOS2がOS1に最適化を要求してもよい。最適化要求手段25は、OS最適化手段23と同様に、OS2利用状況情報32に基づき最適化するソフトウェア2の最適化対象を決定し、OS最適化手段23に最適化対象の最適化を要求する。なお、要求後の処理は同じである。このように、最適化されるOSが最適化すべきことを検出すれば、よりタイミングよくOSを最適化できる。
以上の構成を用いて、OS1がOS2を最適化する手順を図5のフローチャート図に基づき説明する。ソフトウェアの最適化は、予め定められたサイクル(毎日、毎週、毎月)で行ってもよいし、利用状況情報が変動した場合に最適化要求手段25がそれを検出して、OS1に最適化を要求する形で実行してもよい。図5では、予め定められたサイクルで最適化する処理を示す。
図5では、OS2上でアプリケーションプログラムとしてブラウザとエディタが利用されているものとし、これらのソフトウェア2の最適化を実行する。本実施形態では、ブラウザの利用頻度は最適化が必要な程度に低く、エディタは未使用であるとする。
まず、OS1の利用状況情報参照手段22は、OS2利用状況情報32を参照する(S10)。そして、OS最適化手段23は、最適化が必要か否かを判定する(S20)。ブラウザは利用頻度が低く、また、エディタは使用されていないので、OS最適化手段23は、最適化が必要であると判定する。
最適化する場合、OS最適化手段23はOS2に処理状況を通知するよう要求し、処理状況に基づき最適化対象のブラウザとエディタが停止状態か否か、停止状態でなければ停止可能か否かを判定する(S40)。なお、最適化対象が複数の場合は、1つずつ順に最適化する。
停止状態、又は、停止可能の場合(S40のYes)、OS最適化手段23はOS2を最適化する(S50)。
まず、ブラウザの最適化について説明する。OS最適化手段23は、ブラウザの利用頻度が低いので、例えば「できるだけ小さいオブジェクトコードを生成する」、「最低限の機能のみオブジェクトコードを生成する」などのコンパイラオプションをコンパイル手段24に指示する。コンパイル手段24は、ブラウザのソースコードをOS2ソースコード42から読み出し、このようなコンパイラオプションによりオブジェクトコードを生成する。そして、OS最適化手段23は最適化されたブラウザのオブジェクトコードをOS2オブジェクトコード52に記憶させる。
エディタの最適化について説明する。OS最適化手段23は、エディタが未使用であるので、実行されていれば停止し、OS2の起動時に自動的に起動する設定になっていれば自動的に起動しないように設定する。また、エディタが常駐型である場合、常駐しないように設定する。設定は、コンパイルによって行ってもよいし、例えば、設定内容を最適化したメタデータを生成してもよい。OS最適化手段23は最適化されたエディタのオブジェクトコード又はメタデータをOS2オブジェクトコード52に記憶させる。
ついで、OS最適化手段23は、最適化の必要なソフトウェア(ブラウザ、エディタ)の最適化が全て終了したか否かを判定し、終了していなければOS2の処理状況の解析から繰り返す。
最適化の必要なソフトウェアの最適化が全て終了した場合(S60のYes)、OS最適化手段23は、OS2を停止させ残機能を最適化する(S70)。すなわち、OS2のカーネルについてはOS2を停止させないと最適化が困難なので、OS最適化手段23はOS2に停止を要求し、また、OS2のカーネル全体を新たにコンパイルしたカーネルの複製を生成した後、次回のOS2の起動時に新たに生成したカーネルが起動されるように設定して、OS2を再起動する。これにより、OS2のカーネルを最適化することができた。
利用頻度の低いソフトウェア2は、オブジェクトコードを小さくするなどの方法により、例えば最低限、実行に必要な構成とすることで実行可能な状態を保ちつつ、ハードディスク装置14の容量を節約することができる。また、未使用のソフトウェア2については、停止させ、かつ、可能な限り実行することのないように設定することで、発熱や消費電力を低減することができる。なお、エディタのオブジェクトコードは削除していないので、ユーザが例えばエディタを起動する操作をした場合、OS2はエディタを起動する。
続いて、OS2がOS1を最適化する手順を図6のフローチャート図に基づき説明する。最適化の手順はOSが異なっても同じなので、ステップS140以降の、利用状況情報に応じた最適化について説明する。OS1上では、アプリケーションプログラムとしてナビゲーションとメディアプレイヤーが利用されているとして、これらのソフトウェア1の最適化を実行する。また、本実施形態では、ナビゲーションの利用頻度は高頻度であり、メディアプレイヤーはほぼ定期的に音声出力のみが利用されているものとする。図6では、ナビゲーションの最適化が必要で、メディアプレイヤーは最適化が必要でないとする。
最適化する場合、OS最適化手段23はOS2に処理状況を通知するよう要求し、処理状況に基づき最適化対象のナビゲーションとメディアプレイヤーが停止状態か否か、停止状態でなければ停止可能か否かを判定する(S140)。なお、最適化対象が複数の場合は、1つずつ順に最適化する。
停止状態、又は、停止可能の場合(S140のYes)、OS最適化手段23はOS2を最適化する(S150)。
ナビゲーションの最適化について説明する。OS最適化手段23は、ナビゲーションの利用頻度が高いので、例えば「起動時に割り当てるメモリの初期値を最大にする」、「全ての関数のオブジェクトコードを生成する」、などのコンパイラオプションをコンパイル手段24に指示する。
コンパイル手段24は、ナビゲーションのソースコードをOS1ソースコード41から読み出し、このようなコンパイラオプションによりオブジェクトコードを生成する。そして、OS最適化手段23は最適化されたブラウザのオブジェクトコードをOS1オブジェクトコード51に記憶させる。
メディアプレイヤーについては最適化を行わない。全てのソフトウェア1の最適化が終了したら(S160のYes)、以降は、図5のフローチャート図と同様である。すなわち、OS最適化手段23は、OS1を停止させ残機能(カーネル)を最適化する(S170)。
利用頻度の高いソフトウェア1は、例えば全ての要素を利用できる構成とし、また、資源を最大限割り当てるので、ユーザはいつでも快適にソフトウェア1の機能Sを最大限利用することができる。
本実施例によれば、ソフトウェア1,2による機能Sの利用状況情報を記憶しておくことで、機能S毎にユーザの利用頻度を判定し、情報処理装置10を最適化するので、処理を高速化することができる。停止できる機能SについてはOSを起動したまま部分的なコンパイルを動的に行うことができ、常に動作しているカーネルについては他方のOSを完全に停止して最適化することができる。複数のOSを独立して実行可能なので、一方のOSが他方のOSをOSレベルで最適化でき、より詳細な最適化が可能となる。また、不要な機能Sは停止するので、発熱や消費電力を低減できる。
また、本実施例では、図4に示したように、機能S毎(アプリケーションプログラム毎、ライブラリ毎、デバイスドライバ毎)に利用状況情報を記憶した。しかし、例えば、アプリケーションプログラムであれば、機能Sの中にいくつかのサブ機能(画像処理、音声処理、特殊ファイルの表示、特殊な関数の演算等)が存在する場合があるので、サブ機能毎に利用状況情報を記憶しておいてもよい。サブ機能毎に最適化することで、各機能Sをより最適化しやすくすることができる。
また、機能S(例えば実行プログラム)でなく、単に情報を記憶したファイルの場合であっても、アプリケーションプログラムが管理する全てのファイルを使用するとは限らないので、これらファイルのアクセス履歴を記憶しておき、アクセスされないファイルについては圧縮してもよい。例えば、使用されないフォントファイル、地図データファイル、音声案内のメッセージ等、文章のテンプレートファイル等を、圧縮して保存しておくことで処理を高速化することができる。
実施例1ではソフトウェア1、2の利用状況情報に基づき最適化する情報処理装置10について説明したが、ソフトウェア1,2の特性情報を記憶しておくと、ソフトウェア1,2の特性に応じて情報処理装置10を最適化することができる。特性情報とは、例えば画像処理、音声処理の有無、負荷の程度、などソフトウェア1,2の特徴をいう。本実施例では、利用頻度に加えさらに特性情報を利用して最適化する情報処理装置10について説明する。
図7は、本実施例の情報処理装置10の機能ブロック図を示す。なお、図7において頭2と同一部分には同一の符号を付しその説明は省略する。図7の情報処理装置10は、次述するソフトウェアの特性情報を検出する特性情報検出手段26を有する点で図2と異なる。また、図7では、OS2においてナビゲーション、メディアプレイヤー及びブラウザを実行している。
図8は、本実施例の利用状況情報の一例を示す。図8ではアプリケーションプログラムの特性情報を示した。ここでは、「11AA」をナビゲーションと、「12BB」をメディアプレイヤーと、「13CC」をブラウザと、する。また、利用状況情報に示すように、ナビゲーションとメディアプレイヤーが高頻度で、ブラウザは低頻度とした。また、特性情報は、ナビゲーションが「画像処理:有 音声処理:有 負荷:中 」、メディアプレイヤーが「画像処理:無 音声処理:有 負荷:中」、ブラウザが「画像処理:有 音声処理:無 負荷:高」である。
この特性情報は、特性情報検出手段26が検出する。特性情報検出手段26は、例えば、画像処理用のAPI(Application Program Interface)を呼び出すか否か、表示制御装置17の情報処理量、等により画像処理の有無を判定する。また、特性情報検出手段26は、例えば、音声処理用のAPIを呼び出すか否か、スピーカのデバイスドライバが使用されるか否か、等により音声処理の有無を判定する。また、負荷については、例えばCPU負荷率の値を監視して負荷の程度を検出する。特性情報検出手段26は、CPU負荷率のピーク値又は単位時間当たりの積算値等と所定の閾値を比較し、3〜5段階程度に負荷の程度を分類する。
本実施例のOS最適化手段23は、利用状況情報、特性情報及び負荷情報に基づき、最適化対象にする機能S及び方法を決定する。例えば、画像処理や音声処理するソフトウェア1,2であれば、画像処理や音声処理が高速に処理されるよう最適化し、負荷の高いソフトウェア1,2については資源を多く割り当てる。
本実施例においてOS1がOS2を最適化する手順は図5のフローチャート図と同様である。また、OS2がOS1を最適化する手順も同様であるのでこの手順は説明を省略する。
まず、OS1の利用状況情報参照手段22は、OS2利用状況情報32を参照する(S10)。そして、OS最適化手段23は、最適化が必要か否かを判定する(S20)。ここでは、ナビゲーション、メディアプレイヤー及びブラウザの全てに最適化が必要であると判定する。
最適化する場合、OS最適化手段23はOS2に処理状況を通知するよう要求し、処理状況に基づき最適化対象のブラウザとエディタが停止状態か否か、停止状態でなければ停止可能か否かを判定する(S40)。なお、最適化対象が複数の場合は、1つずつ順に最適化する。
停止状態、又は、停止可能の場合(S40のYes)、OS最適化手段23はOS2を最適化する(S50)。
まず、ナビゲーションの場合、利用頻度が高く、また、画像処理と音声処理のいずれも使用されるので、OS最適化手段23は、ナビゲーションを画像処理と音声処理を中心に最適化する。具体的には、例えば、画像処理と音声処理に適した命令セットを積極的に使用してコンパイルするようにコンパイル手段24に要求し、また、画像処理や音声処理の専用のライブラリを利用するように設定する。利用頻度が高いので、実施例1と同様に「起動時に割り当てるメモリの初期値を最大にする」など資源を割り当てるようにして最適化する。処理負荷の大きい画像処理や音声処理専用の命令セットを利用してコンパイルすることで、処理を高速化することができる。なお、画像処理において、例えば3次元の画像処理を多用する場合は、3次元画像処理用の命令セットを割り当てる。
また、メディアプレイヤーの場合、利用頻度が高く、音声処理は利用されているが画像処理は利用されていないので、OS最適化手段23は、メディアプレイヤーを音声処理を中心に最適化し、画像処理等に関するサブ機能を停止する。処理負荷の大きい音声処理専用の命令セットを利用してコンパイルすることで、処理を高速化することができ、また、画像処理等に関するサブ機能を停止するのでオブジェクトコードも小さくなり、さらに処理を高速化し易くできる。
また、ブラウザの場合、利用頻度は低く、また、画像処理が利用されるが音声処理は利用されないので、OS最適化手段23は、ブラウザを、画像処理を中心に最適化する。しかしながらブラウザは利用頻度が低いので、OS最適化手段23は、音声処理等に関するサブ機能を停止すると共に、画像処理について最低限実行できるよう「できるだけ小さいオブジェクトコードを生成する」等のコンパイラオプションによりコンパイラすることで最適化する。したがって、画像処理専用の命令セットは利用しない。
また、ブラウザの場合、利用頻度は低いが実行時の負荷が大きいので、実行までは資源を割り当てる必要がないが、実行時には多くの資源を割り当てることが好ましい。そこで、実行時には必要に応じて他のアプリケーションプログラムよりも優先的に資源が割り当てられるように設定しておく。利用頻度が低いので最低限のオブジェクトコードのみを生成しておき、実行する際は必要に応じて優先的に資源を割り当てるので、実行前は資源を圧迫することなく実行時は高速に処理できる。
ついで、OS最適化手段23は、最適化の必要なソフトウェア(ナビゲーション、メディアプレイヤー、ブラウザ)の最適化が全て終了したか否かを判定し、終了していなければOS2の処理状況の解析から繰り返す。
最適化の必要なソフトウェアの最適化が全て終了した場合(S60のYes)、OS最適化手段23は、OS2を停止させ残機能を最適化する(S70)。すなわち、OS最適化手段23はOS2に停止を要求し、また、OS2のカーネル全体を新たにコンパイルしたカーネルの複製を生成した後、次回のOS2の起動時に新たに生成したカーネルが起動されるように設定して、OS2を再起動する。これにより、OS2のカーネルを最適化することができた。
本実施例によれば、実施例1の効果に加え、利用頻度だけでなくさらに各機能の特性情報に基づきより詳細にソフトウェア1,2を最適化することができる。
情報処理装置のハードウェア構成図である。 情報処理装置の機能ブロック図である。 OSの最適化の概略を説明する説明図である。 利用状況情報の一例を示す図である。 OS1がOS2を最適化する手順のフローチャート図である。 OS2がOS1を最適化する手順のフローチャート図である。 情報処理装置の機能ブロック図である(実施例2)。 利用状況情報の一例を示す図である(実施例2)。
符号の説明
10 情報処理装置
11 CPU
12 RAM
13 ROM
14 ハードディスク装置
15 入力装置
16 ドライブ装置
17 表示制御装置
20 ハードウェア(HW)
21 利用頻度集計手段
22 利用状況情報参照手段
23 OS最適化手段
24 コンパイル手段
25 最適化要求手段
26 特性情報検出手段
31 OS1利用状況情報
32 OS2利用状況情報
41 OS1ソースコード
42 OS2ソースコード
51 OS1オブジェクトコード
52 OS2オブジェクトコード


Claims (5)

  1. 複数のオペレーティングシステムが独立に動作可能な情報処理装置において、
    第2のオペレーティングシステムで実行されるソフトウェアの利用状況情報を記憶した利用状況情報記憶手段と、
    前記利用状況情報を参照する、第1のオペレーティングシステムで実行される利用状況情報参照手段と、
    前記利用状況情報に基づき前記第2のオペレーティングシステムを最適化する、前記第1のオペレーティングシステムで実行されるOS最適化手段と、
    を有することを特徴とする情報処理装置。
  2. 複数のオペレーティングシステムが独立に動作可能な情報処理装置において、
    第2のオペレーティングシステムで実行されるソフトウェアの利用状況情報を記憶した利用状況情報記憶手段と、
    第1のオペレーティングシステムに最適化を要求する、前記第2のオペレーティングシステムで実行される最適化要求手段と、
    前記第2のオペレーティングシステムを最適化する、前記第1のオペレーティングシステムで実行されるOS最適化手段と、
    を有することを特徴とする情報処理装置。
  3. 前記OS最適化手段は、利用頻度が所定以下のソフトウェアを停止する、
    ことを特徴とする請求項1又は2記載の情報処理装置。
  4. 複数のオペレーティングシステムが独立に動作可能な情報処理装置の最適化方法において、
    第1のオペレーティングシステムで実行される利用状況情報参照手段が、第2のオペレーティングシステムで実行されるソフトウェアの利用状況情報を記憶した利用状況情報記憶手段を参照するステップと、
    前記第1のオペレーティングシステムで実行されるOS最適化手段が、前記利用状況情報に基づき前記第2のオペレーティングシステムを最適化するステップと、
    を有することを特徴とする情報処理装置の最適化方法。
  5. 複数のオペレーティングシステムが独立に動作可能なコンピュータを、
    第2のオペレーティングシステムで実行されるソフトウェアの利用状況情報を記憶した利用状況情報記憶手段を参照する、第1のオペレーティングシステムで実行される利用状況情報参照手段と、
    前記利用状況情報に基づき前記第2のオペレーティングシステムを最適化する、前記第1のオペレーティングシステムで実行されるOS最適化手段と、
    として機能させるためのプログラム。

JP2007108531A 2007-04-17 2007-04-17 情報処理装置、情報処理装置の最適化方法、プログラム Pending JP2008269094A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007108531A JP2008269094A (ja) 2007-04-17 2007-04-17 情報処理装置、情報処理装置の最適化方法、プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007108531A JP2008269094A (ja) 2007-04-17 2007-04-17 情報処理装置、情報処理装置の最適化方法、プログラム

Publications (1)

Publication Number Publication Date
JP2008269094A true JP2008269094A (ja) 2008-11-06

Family

ID=40048541

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007108531A Pending JP2008269094A (ja) 2007-04-17 2007-04-17 情報処理装置、情報処理装置の最適化方法、プログラム

Country Status (1)

Country Link
JP (1) JP2008269094A (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112009002507T5 (de) 2008-10-17 2012-01-19 Japan Gore-Tex, Inc. Verstärkte Brennstoffzellen-Elektrolytmembran, Membran/Elektriden-Anordnung für eine Brennstoffzelle und Polymerelektrolyd-Brennstofftelle, inder dies enthalten ist
JP2012243011A (ja) * 2011-05-18 2012-12-10 Ntt Data Corp ソースコード分析装置、ソースコード分析方法およびプログラム
JP2017524212A (ja) * 2015-05-22 2017-08-24 シャオミ・インコーポレイテッド アプリケーションのインストールパッケージの処理方法、装置、プログラム及び記録媒体
WO2020241204A1 (ja) * 2019-05-28 2020-12-03 株式会社デンソー 車両用装置
JP7410268B2 (ja) 2019-07-16 2024-01-09 インターナショナル・ビジネス・マシーンズ・コーポレーション コンテナ・ベースの仮想化システムに関する方法

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112009002507T5 (de) 2008-10-17 2012-01-19 Japan Gore-Tex, Inc. Verstärkte Brennstoffzellen-Elektrolytmembran, Membran/Elektriden-Anordnung für eine Brennstoffzelle und Polymerelektrolyd-Brennstofftelle, inder dies enthalten ist
DE112009002507B4 (de) 2008-10-17 2018-05-24 Japan Gore-Tex, Inc. Verstärkte brennstoffzellen-elektrolytmembran, membran-elektroden-anordnung und polymerelektrolytbrennstoffzelle, diese enthaltend und herstellungsverfahren dazu
DE112009002507B8 (de) 2008-10-17 2018-08-30 Toyota Jidosha Kabushiki Kaisha Verstärkte brennstoffzellen-elektrolytmembran, membran-elektroden-anordnung und polymerelektrolytbrennstoffzelle, diese enthaltend und herstellungsverfahren dazu
JP2012243011A (ja) * 2011-05-18 2012-12-10 Ntt Data Corp ソースコード分析装置、ソースコード分析方法およびプログラム
JP2017524212A (ja) * 2015-05-22 2017-08-24 シャオミ・インコーポレイテッド アプリケーションのインストールパッケージの処理方法、装置、プログラム及び記録媒体
WO2020241204A1 (ja) * 2019-05-28 2020-12-03 株式会社デンソー 車両用装置
JP2020194333A (ja) * 2019-05-28 2020-12-03 株式会社デンソー 車両用装置
JP7131481B2 (ja) 2019-05-28 2022-09-06 株式会社デンソー 車両用装置
US11853103B2 (en) 2019-05-28 2023-12-26 Denso Corporation Vehicular device
JP7410268B2 (ja) 2019-07-16 2024-01-09 インターナショナル・ビジネス・マシーンズ・コーポレーション コンテナ・ベースの仮想化システムに関する方法

Similar Documents

Publication Publication Date Title
JP4921384B2 (ja) メモリを1台のバーチャル・マシンからもう一方へダイナミックに再割り当てする方法、装置及びシステム
JP5385347B2 (ja) メイン・メモリのフリー・メモリ量を拡大する方法およびコンピュータ
JP6370218B2 (ja) メモリ管理方法、コンピュータシステム、コンピュータプログラム及び記憶媒体
JP6138774B2 (ja) コンピュータにより実行される方法及びコンピュータシステム
US20090089780A1 (en) Method and apparatus to convey physical resource relationships
JP5980916B2 (ja) コンピュータにより実行される方法及びコンピュータシステム
JP2014506708A (ja) ハイバネイトからの多段レジューム
JP2008033392A (ja) 仮想計算機システム及びその動作方法
EP2375324A2 (en) Virtualization apparatus for providing a transactional input/output interface
JP2011526714A (ja) ハイパーバイザ・ローディングのためのメモリ管理
JP2008186175A (ja) オペレーティングシステムの起動制御方法及び情報処理装置
JP5200085B2 (ja) コンピュータを短時間で起動する方法およびコンピュータ
JP2008269094A (ja) 情報処理装置、情報処理装置の最適化方法、プログラム
US9342477B2 (en) Multi-core processor, controlling method thereof and computer system with such processor
KR20130068630A (ko) 임베디드 디바이스의 초기화 방법 및 장치
US9910677B2 (en) Operating environment switching between a primary and a secondary operating system
CN113791873B (zh) 一种虚拟机创建方法、计算设备及存储介质
KR100994723B1 (ko) 시스템에서 초기 구동시간을 단축시키는 선택적 서스펜드 리쥼 방법 및 그 기록매체
CN112654965A (zh) 动态模块的外部分页和交换
JP2009266027A (ja) 情報処理装置および制御方法
JP5699665B2 (ja) サーバ装置、処理実行方法およびプログラム
CN107766122B (zh) 一种宿主机的可用内存空间设置方法和装置
JP2012003510A (ja) 計算機及び転送プログラム
JP5417303B2 (ja) 仮想計算機システム及びそのインストール方法
US10241821B2 (en) Interrupt generated random number generator states