JP4517006B2 - クロック制御装置及びその記録媒体 - Google Patents

Description

本発明は、情報処理装置におけるクロック制御装置及びその記録媒体に関し、オペレータの使用環境（電源条件、温度条件、騒音条件）と、使用するアプリケーションとに応じて、情報処理装置のシステムクロックを変更することにより、最適なパフォーマンスをオペレータに提供することができるクロック制御装置及びその記録媒体に関する。

近年、パーソナル・コンピュータ等の情報処理装置においては、高性能化が進んでおり、これに伴って、高速なＣＰＵが搭載されるようになってきた。
しかしながら、高速なＣＰＵを搭載すると、ＣＰＵの動作クロック周波数も高くなるため、ＣＰＵによる消費電力も増大する。

このため、情報処理装置の消費電力の省エネルギー化や、バッテリ内蔵のノート型パソコン等におけるバッテリ持続時間の延長化などの問題が出てくる。
この問題に対処するために、情報処理装置のクロック周波数を制御して、アプリケーション実行時におけるＣＰＵの動作クロック周波数を下げてやる方法が種々開発されている。

これら従来の方法において、例えば、特許文献１、２及び３等に開示されたものでは、情報処理装置におけるクロック制御が、Ｉ／Ｏからのイベント発生に応じて行われるものである。

ところで、実行される複数のアプリケーションの負荷はそれぞれ異なっているものであり、高速のＣＰＵを搭載する情報処理装置において、例えば、負荷の低いアプリケーションに対しても、リソース管理手段が不必要に高いクロックを与えれば、リソースを不必要に浪費するものである。

これに対処する方法が、特許文献４、５などに開示されている。これらの従来の方法では、情報処理装置におけるＣＰＵの処理動作に対応して、事前に、アプリケーションに、処理容量、処理時間、ＣＰＵの使用量を登録しておき、ＣＰＵの処理速度について、アプリケーションの処理容量、処理時間、使用量に基づいて、ＣＰＵのクロック周波数を可変制御している。これらの方法によれば、アプリケーションの負荷状況を監視することとなり、ＣＰＵのより良いクロック制御が可能となるものである。

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

しかし、これらの従来の方法では、マルチタスクでアプリケーションが実行されるときに、アプリケーションの要求リソースが、実際の情報処理装置が有するリソースを上回る場合がある。この様な場合には、オペレータに最適なパフォーマンスを提供することができないばかりでなく、情報処理装置のアップグレード化が必要である。

ところが、情報処理装置のパフォーマンスに関する評価を行い、自動的にオペレータに知らせるという手段は無い。そのため、情報処理装置のアップグレード時期はオペレータの感覚に頼るしかなく、最適な時期でのシステムの更新が出来なかった。
それ故、情報処理装置の更新が必要な時期を求め、オペレータに自動的にアラームする必要がある。

また、上述の従来の方法によれば、実行されるアプリケーション毎に、予め登録された処理容量、処理時間、ＣＰＵの使用量に基づいて、実際の実行時の処理容量と時間を選定してＣＰＵ処理速度を求め、システムクロックを変更しているだけである。これによれば、システムクロックが変更されることによりＣＰＵの処理速度を無用に高速とせず、消費電力の低減となるが、電源条件の厳しい環境下、さらには、温度条件、騒音条件の環境下での情報処理装置の使用については、考慮されていない。

従来の方法では、アプリケーションが必要とする以上のクロックをＣＰＵに与えることにより、電力を無駄に消費し、例えば、ノート型パソコンのバッテリ寿命を一層短くするという問題があるばかりでなく、また、バッテリの残容量が少なくなった場合に、最適なパフォーマンスは期待しないが、使用しなければならない時間に応じ、その残容量を有効に消費して、バッテリを長持ちさせたいという問題があった。

さらに、従来の方法では、情報処理装置の発熱に対して、ファン等を利用した強制冷却という手段で対応している。情報処理装置の冷却系については、設計段階で予測しえる最大の発熱量に対応できる冷却能力を備えるのが通例である。

そうすると、情報処理装置において、現実のアプリケーショシ実行中では、強制冷却が必要な程のパフォーマンスを要求していない場合でも、最大の発熱量に対応する強制冷却が行われ、発熱量が少なくなってもそれによる騒音を発生させている。情報処理装置を使用する環境における外部騒音が大きい場合には問題とならないが、外部騒音が少ない場合には情報処理装置による発生騒音が目立つという問題があった。
本発明は、上記の問題点を解決することを目的とする。

本発明は上記課題を解決するため、複数のアプリケーションを実行できる情報処理装置において、前記各アプリケーションから読み取られた実行上必要なクロック周波数を、前記複数のアプリケーション毎に登録する記憶部と、前記記憶部に登録された前記各クロック周波数に基づいて、前記アプリケーション毎に、前記各アプリケーションを実行する前記情報処理装置が採りえる最大のクロック周波数に対する前記情報処理装置のＣＰＵ使用率を演算し、演算された前記アプリケーション毎の前記各ＣＰＵ使用率の総和と前記最大のクロック周波数との乗算に基づいて、前記情報処理装置のシステムクロック周波数を決定し、該システムクロック周波数を設定する制御部を含め、前記制御部は、前記決定されたシステムクロック周波数が、前記最大のクロック周波数を超えたとき、クロック周波数超過アラームを送出し、前記システムクロック周波数が前記最大のクロック周波数を超える頻度が増大する場合、前記情報処理装置のアップグレード必要性アラームを送出することとした。

さらに、本発明よる情報処理装置において、前記各アプリケーションから読み取られた実行上必要なクロック周波数を、前記複数のアプリケーション毎に登録する記憶部と、前記記憶部に登録された前記各クロック周波数に基づいて、前記アプリケーション毎に、前記各アプリケーションを実行する前記情報処理装置が採りえる最大のクロック周波数に対する前記情報処理装置のＣＰＵ使用率を演算し、演算された前記アプリケーション毎の前記各ＣＰＵ使用率の総和と前記最大のクロック周波数との乗算に基づいて、前記情報処理装置のシステムクロック周波数を決定し、該システムクロック周波数を設定する制御部を含め、前記制御部は、前記決定されたシステムクロック周波数が、前記最大のクロック周波数を超える頻度が増大する場合、前記情報処理装置のアップグレード必要性アラームを送出することとした。

また、本発明によるプログラムを記録した記録媒体において、複数のアプリケーションを実行するときに、前記各アプリケーションから、当該アプリケーションが実行上快適に動作する第１クロック周波数と、当該アプリケーションが動作上最低限必要な第２クロック周波数とを読み取り、前記複数のアプリケーション毎に登録し、登録された前記各クロック周波数に基づいて、前記アプリケーション毎に、前記各アプリケーションを実行する情報処理システムが採りえる最大のクロック周波数に対する前記情報処理システムにおけるＣＰＵ使用率を演算し、演算された前記アプリケーション毎の前記各ＣＰＵ使用率の総和と前記最大のクロック周波数との乗算に基づいて、前記情報処理システムのシステムクロック周波数を決定し、該システムクロック周波数を設定し、前記決定されたシステムクロック周波数が、前記最大のクロック周波数を超えたとき、クロック周波数超過アラームを送出し、前記システムクロック周波数が前記最大のクロック周波数を超える頻度が増大する場合、前記情報処理システムのアップグレード必要性アラームを送出することを実行させることとした。

さらに、本発明によるプログラムを記録した記録媒体において、複数のアプリケーションを実行するときに、前記各アプリケーションから、当該アプリケーションが実行上快適に動作する第１クロック周波数と、当該アプリケーションが動作上最低限必要な第２クロック周波数とを読み取り、前記複数のアプリケーション毎に登録し、登録された前記各クロック周波数に基づいて、前記アプリケーション毎に、前記各アプリケーションを実行する情報処理システムが採りえる最大のクロック周波数に対する前記情報処理システムにおけるＣＰＵ使用率を演算し、演算された前記アプリケーション毎の前記各ＣＰＵ使用率の総和と前記最大のクロック周波数との乗算に基づいて、前記情報処理システムのシステムクロック周波数を決定し、該システムクロック周波数を設定し、前記決定されたシステムクロック周波数が、前記最大のクロック周波数を超える頻度が増大する場合、前記情報処理システムのアップグレード必要性アラームを送出することを実行させることとした。

このように、本発明によれば、各アプリケーションに係る実行上必要な前記クロック周波数として、当該アプリケーションが快適に動作するクロック周波数と、当該アプリケーションが動作上最低限必要なクロック周波数とを登録し、これらに対応するＣＰＵ使用率を求めることができる。そのため、電源条件、温度条件及び騒音条件の使用条件と使用するアプリケーションとに応じて、情報処理装置のシステムクロックを変更することが可能となり、最適なパフォーマンスをオペレータに提供することができる。

図１は、情報処理装置におけるリソース管理手段の概略ブロック図である。 図２は、リソース管理手段内に備えられる第１管理テーブルを示す図である。 図３は、図１に示されたリソース管理手段の動作を説明するフローチャート図である。 図４は、情報処理装置に関するアップグレードの必要性をアラームする場合におけるリソース管理手段の動作を説明するフローチャート図である。 図５は、電源条件に従って情報処理装置のシステムクロックを変更するリソース管理手段の概略ブロック図である。 図６は、リソース管理手段内に備えられる第２管理テーブルを示す図である。 図７は、図５に示されたリソース管理手段の動作を説明するフローチャート図である。 図８は、バッテリ残容量に応じて情報処理装置のシステムクロックを変更するリソース管理手段の概略ブロック図である。 図９Ａは、図８に示されたリソース管理手段の動作を説明するフローチャート図である。 図９Ｂは、図９Ａに示されたリソース管理手段の動作を説明するフローチャート図の続きである。 図１０は、温度条件に従って情報処理装置のシステムクロックを変更するリソース管理手段の概略ブロック図である。 図１１は、図１０に示されたリソース管理手段の動作を説明するフローチャート図である。 図１２は、使用環境に合わせて情報処理装置から発生する雑音を抑制するリソース管理手段の概略ブロック図である。 図１３は、リソース管理手段内に備えられる第３管理テーブルを示す図である。 図１４は、図１２に示されたリソース管理手段の動作を説明するフローチャート図である。

本発明による実施形態を説明する前に、本発明の基礎となる形態について、図１乃至図４を参照して説明する。

図１は、情報処理装置、例えば、パーソナル・コンピュータ（ＰＣ）におけるリソース管理手段について、リソース管理に係わる部分の概略をブロックで示している。

図１に示されたＰＣは、ＣＰＵ１を備えており、例えば、ＷＩＮＤＯＷＳ（登録商標） のようなＯＳにより各種アプリケーションを実行できるように構成されている。そして、このＰＣを駆動するために、これらＯＳ、各種アプリケーションのリソースを管理するリソース管理手段２が用意されている。

図１においては、アプリケーション４、５として、ＡＰ１及びＡＰ２を模式的に示しているが、ＰＣには、複数のアプリケーションＡＰｎが格納されているのが普通であり。特に、図１では、マルチタスクで２つのアプリケーションＡＰ１及びＡＰ２が実行中であるものとして表した。

リソース管理手段２は、記憶部２１、制御部２２を有し、記憶部２１には、リソース管理上必要な情報が格納され、制御部２２は、このリソース管理情報に基づいて、ＰＣを駆動制御する。さらに、制御部２２は、ＣＰＵ１についてシステムクロック下でのＣＰＵ使用率を監視し、測定する機能を有する。

ＰＣには、システムクロックを発生し、ＣＰＵ１にシステムクロックを供給するＣＰＵクロック制御回路が備えられており、制御部２２の指示により、発生するクロック周波数が可変制御される。

記憶部２１には、リソース管理情報の一つとして、アプリケーション毎に快適動作のクロック周波数を取り込み、記憶しておく。快適動作のクロック周波数とは、当該アプリケーション実行中において、オペレータがＰＣの快適動作と感じる当該アプリケーション特有のクロック周波数である。

これは、アプリケーション・ベンダーが、どの程度であれば快適動作であるかを考慮して、予めアプリケーションに書き込んでおく。そして、ＰＣを駆動する際に、マルチタスクで係わるアプリケーションのそれぞれから、各アプリケーションに書き込まれた快適動作のクロック周波数を取り出し、図２に示す第１管理テーブルを作成し、記憶部２１に記憶する。

最近のＰＣでは、一般に、高速化が進んでおり、これら実行されるアプリケーションの快適動作のクロック周波数より早い速度のクロックが使用されている。そのため、ＣＰＵが、この様な高速のクロック周波数で動作しても、オペレータによるキーボード操作待ち、ＣＤ−ＲＯＭ等におけるストレージ・アクセス待ちのように、実際には、ＣＰＵ自体が動作せず、待機状態になり、全体のＣＰＵ使用率を下げている。各アプリケーションに対する快適動作のクロック周波数を設定することは、このＣＰＵ使用率の低下にも対処するものである。

図２では、図１に示されるように、アプリケーションＡＰ１及びＡＰ２が実行されるので、アプリケーションＡＰ１から３０MHz を、アプリケーションＡＰ２から６０MHz を取り出して、テーブルに記憶する。また、ＯＳに対しても快適動作として、「リソース管理」アプリケーション欄に３０MHz を記憶する。

なお、アプリケーション・ベンダーが快適動作のクロック周波数を予めアプリケーションに書き込んでおくようにしたが、オペレータが快適動作のクロック周波数をアプリケーション毎に第１管理テーブルに記憶するようにしてもよい。

次いで、制御部２２は、第１管理テーブルに記憶されたクロック周波数に基づいて、各アプリケーションについて、快適動作のクロックでＣＰＵを駆動する場合のＣＰＵ使用率を算出し、該テーブルに記憶する。この算出に当たっては、今使用しているＰＣが採りえる最大のクロック周波数を用いる。これは、通常、ＰＣの動作速度に関する性能を表すクロック周波数となる。

図２に示した例では、ＰＣが採りえる最大のクロック周波数を３００MHz とした場合を示しており、アプリケーションＡＰ１の快適動作のクロック周波数が３０MHz であるので、アプリケーションＡＰ１の実行中のＣＰＵ使用率は１０％となり、また、アプリケーションＡＰ２のそれが６０MHz であるので、そのＣＰＵ使用率は２０％となる。同様に、リソース管理のＣＰＵ使用率は１０％となる。

そこで、各アプリケーションがマルチタスクで実行されるので、ＰＣとしてのＣＰＵ使用率は、実行されるアプリケーション毎のＣＰＵ使用率の総和となる。図２の例によれば、そのＣＰＵ使用率の総和は、４０％となる。

それ故、ＰＣとしては、システムクロック周波数が３００MHz であっても、このクロック周波数の内、４０％分のクロック周波数で動作すれば十分であり、オペレータは、ＰＣを快適に操作していると感ずることができる。３００MHz ×４０％＝１２０MHz となり、ＰＣのシステムクロック周波数を３００MHz から１２０MHz に変更すればよい。

制御部２２は、ＣＰＵ使用率の総和からＰＣのシステムクロック周波数を求め、ＣＰＵクロック制御回路３に対して、３００MHz から１２０MHz に変更する指示を出す。そして、ＣＰＵクロック制御回路３は、変更した１２０MHz のクロックをＣＰＵ１に供給する。
以上のように、ＰＣの負荷量に応じて、つまり実行されるアプリケーションに応じて、アプリケーション毎の快適動作のクロック周波数を把握することにより、ＣＰＵ使用率の総和からクロック周波数を求める。そして、そのクロック周波数がシステムクロック周波数に決定される。

次に、図１に示されたリソース管理手段２の動作について、図３のフローチャートを参照して説明する。

マルチタスクで各アプリケーションの実行が開始されると、リソース管理手段２は、実行に係わる各アプリケーションＡＰｎから快適動作のクロック周波数を取り出し、図２に示した第１管理テーブルを作成し、記憶する。そして、該テーブルに記憶したアプリケーションＡＰｎ毎のクロック周波数に基づいて、アプリケーションＡＰｎ毎のＣＰＵ使用率を求める（ステップＳ１０１）。そのＣＰＵ使用率は、この時のＰＣが採りえる最大のクロック周波数を基に算出する。

リソース管理手段２は、アプリケーションＡＰｎ毎のＣＰＵ使用率が求めた後に、アプリケーションＡＰｎ毎のＣＰＵ使用率の総和を求め、最大クロック周波数により前記ＰＣとして快適動作を行えるシステムクロック周波数を求め、設定する。そして、ＣＰＵクロック制御回路３は、求められたシステムクロック周波数に変更制御して、ＣＰＵ１にこのシステムクロックを供給する（ステップＳ１０２）。

ＰＣが、新たに設定されたシステムクロック周波数で動作すると、リソース管理手段２は、現在動作中のＣＰＵにおけるＣＰＵ使用率を測定する（ステップＳ１０３）。

このとき、測定されたＣＰＵ使用率が１００％であるかどうかを判断する（ステップＳ１０４）。もし、ＣＰＵ使用率が１００％であると、設定したシステムクロック周波数では、複数のアプリケーションＡＰｎを実行するには、ＣＰＵ１の駆動が遅くなっている可能性があるからである。

ステップＳ１０４で、測定されたＣＰＵ使用率が１００％である場合（Ｙ）、ステップＳ１０１に戻り、複数のアプリケーションＡＰｎ毎のＣＰＵ使用率を求め、ステップＳ１０２に進み、システムクロック周波数を設定し直す。

一方、ステップＳ１０４で、測定されたＣＰＵ使用率が１００％でない場合（Ｎ）には、測定されたＣＰＵ使用率が１００％に近い状態でＣＰＵが動作しているかを判断する（ステップＳ１０５）。１００％に近い状態とは、１００％以下であるが、例えば、９５〜１００％であり、ＣＰＵの動作としては、多少余裕があり、しかも最も効率的に動作している状態を意味している。

ここで、測定されたＣＰＵ使用率が１００％に近い状態の場合（Ｙ）には、設定されているクロック周波数でＣＰＵの駆動を続行すればよいので、ステップＳ１０３に戻り、ＣＰＵ使用率を測定し、監視を続ける。
また、ステップＳ１０５で、測定されたＣＰＵ使用率が１００％には遠い状態の場合（Ｎ）には、システムクロック周波数を設定し直すべく、ステップＳ１０１に戻る。

この様に、実行される複数のアプリケーションに応じて、アプリケーション毎の快適動作のクロック周波数からシステムクロック周波数を求め、これを、ＰＣのシステムクロックに設定するので、オペレータが快適にアプリケーションを使用することができる。

これまで、図１に示したリソース管理手段２によって、複数のアプリケーションを実行する場合において、オペレータが快適にアプリケーションを使用することができるようにできた。しかし、多くのアプリケーションを実行するとき、ＰＣが採りえる最大のクロック周波数が、元々低い場合には、アプリケーション個々の快適動作のクロック周波数がその最大クロック周波数より小さくても、ＰＣとして過負荷の状態になる可能性がある。つまり、多くのアプリケーションを実行するには、性能不足といえる。

この様な状態では、オペレータが快適にアプリケーションを使用することができるとはいえないので、ＰＣの性能不足によって快適動作がなされていないことをアラームすることができれば、オペレータは、ＰＣのアップグレードの必要性に簡単に気付くことができる。

これに使用されるリソース管理手段２は、図１に示されたブロック構成でよいが、制御部２２に、ＣＰＵ１の性能不足を判断できる機能を付加し、この判断結果に応じて動作するアラーム手段が接続される。アラーム手段には、ランプ等の点滅、あるいはＰＣ画面上でのメッセージ表示等を利用できる。

この場合のリソース管理手段２の動作について、図４のフローチャートを参照して説明する。

図４のフローチャートに示される動作では、図３に示されたフローチャートのステップＳ１０１からステップＳ１０５までの動作と基本的には同様であるが、ステップＳ２０３の動作が挿入されていることが特徴である。ここでは、図３と同様の動作部分についての説明を省略する。

ステップＳ２０３では、ステップＳ２０２において設定されたシステムクロック周波数について、ＰＣが採りえる最大のクロック周波数より低いかどうかが判断される。ここで、もし、設定されたシステムクロック周波数が、最大クロック周波数より低い場合（Ｙ）、ＣＰＵ１の性能不足とはいえないので、ステップＳ２０４に進み、以降の動作は、図３のステップＳ１０３からステップＳ１０５の動作と同様である。

一方、ステップＳ２０３で、設定されたシステムクロック周波数が、最大クロック周波数より高いと判断された場合（Ｎ）、ＣＰＵ１の性能不足の可能性があるので、ログにＣＰＵ性能不足を記録する（ステップＳ２０７）。

しかし、ＣＰＵ１の性能不足という判断結果が、例えば、数度出ただけでは、一時的に性能不足に陥ったに過ぎず、アップグレードする程ではない可能性もある。そのため、ＣＰＵ１の性能不足という判断結果が度重なって頻発する場合には、アップグレードする必要があると判断する（ステップＳ２０８）。

ステップＳ２０８で、性能不足という判断結果が数度に止まる場合（Ｎ）、アップグレードの必要性はないので、ステップＳ２０１に戻り、システムクロック周波数を設定し直す動作に進む。また、性能不足が頻発している場合（Ｙ）、ＣＰＵ１の性能不足によるアップグレードの必要性ありとして、アラームを発する（ステップＳ２０９）。

この様な動作をリソース管理手段２に追加することにより、ＰＣの性能不足によって快適動作がなされていないことをアラームすることができ、オペレータは、ＰＣのアップグレードの必要性に簡単に気付くことができる。

以上で述べたリソース管理手段２によれば、オペレータが快適にアプリケーションを使用できるように、ＰＣのシステムクロックを最大クロック周波数より低く設定して、ＰＣ全体のＣＰＵ使用率を上げていた。

また、オペレータが快適にアプリケーションを使用できるように、実行されるアプリケーションに応じて、アプリケーション毎の快適動作のクロック周波数を把握して、システムクロック周波数を制御することに加えて、バッテリの残容量が少なくなったときの電源条件、ＣＰＵの発熱量に対応する温度条件、さらには、使用環境に対応してＰＣのから発生する雑音を抑制する環境条件に基づいて、システムクロック周波数を変更制御することにより、オペレータがより快適にアプリケーションを使用できるようになる。

そこで、オペレータの使用環境について、電源条件、温度条件及び環境条件による場合に分けて、図５乃至図１４を参照しながら、以下に説明する。

〔電源条件による場合〕
図５に示したリソース管理手段２が、図１に示したリソース管理手段２と異なる部分は、制御部２２が、電源制御回路６からバッテリ残容量に関する情報を取得できるようになっていることである。電源制御回路６には、バッテリ６１が接続されており、バッテリ使用量に関するデータベースを保持している。さらに、記憶部２１内に格納されるリソース管理テーブルには、複数のアプリケーションＡＰｎ毎に、快適動作のクロックの他に、最低限動作のクロックをも記憶できるようにしたことである。

この快適動作のクロックの他に、最低限動作のクロックをも記憶できるようにした第２管理テーブルを、図６に示す。第２管理テーブルの基本的構成は、図２の第１管理テーブルと同様であるが、アプリケーション毎に、最低限動作のクロックをさらに記憶できる。
最低限動作のクロックとは、オペレータがアプリケーションを快適には使用できないが、実用上の使用には耐えられる最低限必要なクロック周波数を意味している。これは、アプリケーション毎に、アプリケーション・ベンダーが予めアプリケーションに書き込んでおくものである。

アプリケーションが実行されるときに、リソース管理手段２が、書き込まれている快適動作のクロック周波数と共に、最低限動作のクロック周波数を取り出し、記憶部２１内に記憶して、第２管理テーブルを作成する。

図６に示す例によれば、最低限動作のクロック周波数は、アプリケーションＡＰ１が、１０MHz 、アプリケーションＡＰ２が、２０MHz 、そしてリソース管理が、１０MHz となっている。制御部２２は、これらの最低限動作のクロック周波数に基づいて、最低限動作時のＣＰＵ使用率を算出する。ここで、ＰＣの採りえる最大のクロック周波数が３００MHz として、アプリケーション毎に、最低限動作時のＣＰＵ使用率を求めると、アプリケーションＡＰ１が、３．３％、アプリケーションＡＰ２が、６．６％、そしてリソース管理が、３．３％となる。

全体の最低限動作時のＣＰＵ使用率は、各アプリケーションのＣＰＵ使用率の総和となるので、図６の例では、その総和は、１３．３％となる。ＰＣの採りえる最大のクロック周波数が３００MHz の場合には、最低限動作時のシステムクロック周波数は、３００MHz ×１３．３％＝４０MHz となる。

この様にして求めたクロック周波数をシステムクロック周波数として設定することにより、３００MHz のシステムクロックである場合に比較して、最低限動作時に移行した場合において、ＣＰＵの消費電力が大幅に減らすことができ、バッテリの残容量が減少したときにおいて、ＰＣの動作時間を延ばすことができる。

次に、図５のリソース管理手段２の動作について、図７のフローチャートを参照して説明する。

マルチタスクで各アプリケーションの実行が開始されると、リソース管理手段２は、実行に係わる各アプリケーションＡＰｎから快適動作のクロック周波数と最低限動作のクロック周波数とを取り出し、図６に示した第２管理テーブルを作成し、記憶する。そして、該テーブルに記憶したアプリケーションＡＰｎ毎のクロック周波数に基づいて、アプリケーションＡＰｎ毎に、最適動作のＣＰＵ使用率と最低限動作のＣＰＵ使用率とをそれぞれ求める（ステップＳ３０１）。それらのＣＰＵ使用率は、この時のＰＣが採りえる最大のクロック周波数を基に算出する。

リソース管理手段２は、アプリケーションＡＰｎ毎の最適動作時のＣＰＵ使用率と最低限動作時のＣＰＵ使用率を求めた後に、それぞれの動作時に対応して、ＣＰＵ使用率の総和を求めておく。
ここで、制御部２２は、電源制御回路６からバッテリ残容量のデータを読みだし、バッテリ残容量を測定する（ステップＳ３０２）。

予めバッテリ残容量の大きさに対応して、システムクロック周波数を設定しておく。バッテリ残容量が、例えば、５０〜１００％では、快適動作時のクロック周波数、５０〜２５％では、快適動作時と最低限動作時との中間のクロック周波数、そして２５％以下では最低限動作時のクロック周波数、というように選定基準を設定しておき、バッテリ残容量に応じて段階的にシステムクロックを変更できるようにする。さらに細かく多段階で設定しても良い。勿論、ＣＰＵクロック制御回路３も、制御部２２の指示により、この段階的変更に対応してシステムクロックを供給できるように設計しておく。

ステップＳ３０１で測定したバッテリ残容量に応じて、上記の選定基準を参照してＣＰＵに供給するシステムクロック周波数を求める（ステップＳ３０２）。
ここで求めたシステムクロック周波数が、最低限動作に必要なクロック周波数以上であるかどうかが判断される（ステップＳ３０４）。これは、最低限動作時のクロック周波数ということになれば、バッテリ残容量が相当少なくなっていることを表しているので、アプリケーションを使用中に、バッテリ切れを生ずる可能性が大きいからである。

ステップＳ３０３で求められたクロック周波数が、最低限動作時のクロック周波数より高い場合（Ｙ）には、その求めたクロック周波数をＰＣのシステムクロックとして設定する（ステップＳ３０５）。このステップＳ３０５以降のステップＳ３０６からステップＳ３０８までの動作は、図３におけるステップＳ１０３からステップＳ１０５の動作と同様である。

ただ、図７に示す動作では、バッテリ残容量に対応してクロック周波数を求めているので、測定されたＣＰＵ使用率が１００％に近い場合（ステップＳ３０８のＹ）には、バッテリ残容量を監視し続けるため、ステップＳ３０２に戻る。

一方、ステップＳ３０３で求めたクロック周波数が、最低限動作のクロック周波数になった場合（ステップＳ３０４のＮ）には、その求めたクロック周波数、つまり最低限動作のクロック周波数をＰＣのシステムクロックとして設定する（ステップＳ３０９）。そこで、最低限動作のクロック周波数がＰＣのシステムクロックとして設定されると、バッテリ残容量が少ないことを意味する。オペレータがアプリケーションを運用中に、バッテリ切れを起こす可能性が大きくなるので、オペレータにバッテリ切れの可能性があることをアラームで通知する（ステップＳ３１０）。オペレータがこのアラームに気付けば、アプリケーションの運用を中止するか、又はバッテリ充電を開始することができる。

そして、アラームを通知後には、ステップＳ３０１に戻り、システムクロック周波数の設定し直しを行う。

以上のように、ＰＣの負荷に対応し、しかもバッテリ残容量に応じて、ＰＣのシステムクロック周波数を変更するようにしたので、オペレータがアプリケーションを快適に使用できるばかりでなく、ＰＣの使用時間を長く延ばすことが可能となる。そして、アプリケーション使用中でのバッテリ切れを事前に把握することができる。

これまで図５乃至図７を参照して説明した実施形態では、オペレータの実使用予定時間を考慮せずに、単純にバッテリ残容量と、アプリケーション情報（快適な動作を行うクロック周波数〜最低限必要なクロック周波数）により、クロックを変化させることにより、バッテリ寿命と快適なパフォーマンスのバランスを目指した。ところが、実際のノート型パソコンの使用環境においては、例えば、飛行機の移動時問に操作を行えれば良い、あるいは会議時間中だけ操作したい等、ある時間内だけは極力快適なクロック周波数での操作を行える様にしたい、という要望には答えられない。

そこで、図５のリソース管理手段２に対して、事前にオペレータによる実使用予定時間の入力を行い、リソース管理手段が、バッテリ残容量と実使用予定時間とをベースに、ＣＰＵクロック毎の単位時間当たりのバッテリ使用量データベースにアクセスすることにより、オペレータの実使用時問中には、極力快適なパフォーマンスとなるクロック周波数を算出できるようにした。

図８に、実使用予定時間を入力できるリソース管理手段を示すが、図５に示したリソース管理手段と同様の構成であり、同じ部分には同じ符号を付した。

図８に示したリソース管理手段２が、図５のリソース管理手段２とは、制御部２２に入力手段７を接続している点である。この入力手段７は、具体的には、ノートパソコンに付属するキーボード、マウス等であるが、アプリケーションの実行前において、オペレータがリソース管理手段２に実使用予定時間を予め入力できる機能を有するものである。

次に、図８のリソース管理手段２の動作を、図９Ａ及び図９Ｂのフローチャートを参照して説明する。

図９ＡのステップＳ４０１とステップＳ４０２では、図７のステップＳ３０１とステップＳ３０２と同様の動作であり、図６に示した第２管理テーブルを作成し、その後、バッテリ残容量を測定する。
ここで、アプリケーションを使用する前に、オペレータによって、その予定時間が入力されているかどうかを確認する（ステップＳ４０３）。

このとき、当該予定時間が入力されてない場合（Ｎ）には、図７におけるステップＳ３０３以降の動作のように、バッテリ残容量に応じたＣＰＵクロック周波数を設定してもよいが、図９Ａのフローチャートでは、ＣＰＵクロックとして、図６の第２管理テーブルから最低限動作に必要なクロック周波数を求め、ＰＣのシステムクロックを設定する（ステップＳ４０４）。

ＰＣのシステムクロックが設定された後のステップＳ４０５からステップＳ４０７の動作は、図３のステップＳ１０３からステップＳ１０５の動作と同様であるので、その説明を省略する。

一方、ステップＳ４０３で、オペレータによるオペレーション予定時間の入力が確認できた場合（Ｙ）には、測定されたバッテリ残容量と入力されている予定時間とから、ＣＰＵクロック周波数を求める（ステップＳ４０８）。

例えば、ＣＰＵクロック周波数が決まれば、単位時間当たりのＣＰＵ消費電力を求めることができる。それ故、この単位時間当たりのＣＰＵ消費電力を用いて、測定されたバッテリ残容量からオペレーション可能時間を求めることができ、このときのＣＰＵクロック周波数を特定できる。

そこで、求めたオペレーション可能時間が入力された予定時間よりも長くなるように、ＣＰＵクロック周波数を求めることになる。
ここで求められたＣＰＵクロック周波数が最低限動作に必要なクロック周波数でなければならないので、求められたＣＰＵクロック周波数が最低限動作のクロック周波数を超えているかどうかを判断する（ステップＳ４０９）。

その求められたＣＰＵクロック周波数が最低限動作のクロック周波数を超えている場合（Ｙ）には、その求められたＣＰＵクロック周波数をシステムクロックとして設定する（ステップＳ４１０）。これ以降のステップＳ４１１からステップＳ４１３の動作は、ステップＳ４０５からステップＳ４０７の動作と同様であるが、測定されたＣＰＵ使用率が１００％に遠い場合（ステップＳ４１３のＮ）には、実行しているアプリケーションに対しては、未だクロック周波数を上げることができる可能性が有ることを示しているので、ステップＳ４０８に戻り、クロック周波数を設定し直す。

一方、ステップＳ４０９で、求められたＣＰＵクロック周波数が最低限動作のクロック周波数である場合（Ｎ）には、ステップＳ４１４及びステップＳ４１５の動作に進むが、図７のステップＳ３０９及びステップＳ３１０の動作と同様に、システムクロックとして最低限動作のクロック周波数を設定し、オペレータにバッテリ切れの可能性のアラームを通知する。

この様に、オペレータによってオペレーション予定時間を入力できるようにしたので、その予定時間内においてバッテリ残容量に応じた最適なパフォーマンス実行することができ、バッテリ切れにも対処でき、しかも、バッテリ持続時間の延長も可能である。

〔温度条件による場合〕
以上では、バッテリ残容量に応じて、快適なアプリケーション使用をできるようにするという観点であったが、ここで説明する実施形態は、ＰＣの温度に応じて快適なアプリケーション使用をできるようにするという観点に基づいている。

一般的に、アプリケーション実行時には、ＣＰＵクロック周波数が高くなるとＣＰＵからの発熱量が大きくなり、ＣＰＵクロック周波数が低くなるとＣＰＵからの発熱量が少なくなる。従って、最近の高性能なＰＣでは、システムクロックとして高いクロック周波数が固定的に設定されているため、その発熱量は、相当大きくなっている。その発熱量を抑えることが必要である。

この実施形態では、ＰＣ内の熱に弱い部品、発熱部品等の温度を測定できるように、例えば、ＣＰＵの近傍に温度センサを設置しておき、その温度センサで測定される温度の高低に応じて、快適なアプリケーションの実行をしながら、そのＣＰＵの発熱量を抑えるようにシステムクロックを変更するものである。

この実施形態に用いるリソース管理手段を、図１０に示す。
図１０に示されたリソース管理手段の構成は、図５のリソース管理手段と同様であり、同じ部分には同じ符号を付してある。しかし、図１０のリソース管理手段２には、ＣＰＵ１の近傍に温度センサ８が付加されており、制御部２２によってＣＰＵ１の近傍の温度を測定できるようになっている。

図１０に示したリソース管理手段２の動作を、図１１のフローチャートを参照して説明する。

先ず、マルチタスクで各アプリケーションの実行が開始されると、図７のステップＳ３０１と同様に、リソース管理手段２は、実行に係わる各アプリケーションＡＰｎから快適動作のクロック周波数と最低限動作のクロック周波数とを取り出し、図６に示した第２管理テーブルを作成し、記憶する。そして、該テーブルに記憶したアプリケーションＡＰｎ毎のクロック周波数に基づいて、アプリケーションＡＰｎ毎に、この時のＰＣが採りえる最大のクロック周波数を基にして、最適動作のＣＰＵ使用率と最低限動作のＣＰＵ使用率とをそれぞれ求める（ステップＳ５０１）。

次に、リソース管理手段２は、温度センサ８を用いてＣＰＵ１の近傍の温度を測定し、発熱部品の温度情報を取得する（ステップＳ５０２）。
測定された温度が、ＣＰＵ１が誤動作を起こさない範囲で動作しているかどうかが判断される（ステップＳ５０３）。通常、電子機器部品のこの範囲は、１０℃〜６０℃を定格として設計されているので、この範囲を、誤動作を起こさない範囲の温度とする。

ここで、測定された温度が、この範囲を外れて、例えば、６０℃を超えている場合（Ｎ）、ＣＰＵ１が誤動作を起こす危険性が高くなるので、ＣＰＵクロック周波数を下げて、ＣＰＵ１の発熱量を抑える必要がある。そのため、アプリケーションの実行上、最低限動作に必要なクロック周波数をシステムクロックとして設定して（ステップＳ５０４）、ＣＰＵ１からの発熱量を低くする。

そして、ステップＳ５０１及びステップＳ５０２に戻って、再びＣＰＵ１の近傍の温度を測定して、その温度が誤動作を起こさない範囲であるかを監視する。

一方、ステップＳ５０３で、測定された温度が誤動作を起こさない範囲内にある場合（Ｙ）であっても、誤動作を起こさない範囲の境界に接近していることもありえることであり、誤動作を起こさないとする保証はない。そこで、十分な温度マージンで動作しているかを判断する（ステップＳ５０５）。誤動作を起こさない範囲が、１０℃〜６０℃であるとすれば、十分な温度マージンを有する範囲を、１５℃〜５５℃のように設定する。

そうすると、ステップＳ５０２で測定された温度が、十分な温度マージンを有する範囲内にある場合（Ｙ）には、現在設定されているシステムクロック周波数より高いクロック周波数で動作させても、未だＣＰＵ１の発熱量が低いことになるので、システムクロック周波数を決められた所定幅のステップで、例えば、１０MHz だけ上げて、この周波数をシステムクロックとして設定する（ステップＳ５０６）。

また、ステップＳ５０２で測定された温度が、十分な温度マージンを有する範囲を超えている場合（Ｎ）には、現在設定されているシステムクロック周波数で動作させ続けると、その温度が、誤動作を起こさない範囲の限界値に近づく可能性がある。そのため、より低いクロック周波数で動作させた方が安全であるということになるので、この場合も、システムクロック周波数を決められた所定幅のステップで、例えば、１０MHz だけ下げて、これをシステムクロックとして設定する（ステップＳ５０７）。

以上のように、この実施形態では、ＣＰＵ近傍の温度を測定し、その温度に基づいて、誤動作しない範囲と十分な温度マージンを有する範囲とを考慮して、ＣＰＵクロック周波数の設定を行うようにしたので、快適なアプリケーションの実行をできるばかりでなく、ＣＰＵからの発熱量を抑制でき、しかも熱に弱い部品への影響を低減でき、ＰＣの動作を最適化できる。

〔騒音条件による場合〕
上述の実施形態では、ＣＰＵクロック周波数の制御は、熱に弱い部品に付けられた温度センサの温度情報とアプリケーション情報（快適な動作を行うクロック周波数、最低限必要なクロック周波数）に従って、システムクロック周波数を変化させることにより、ＰＣが誤動作を起こさない範囲で、ＣＰＵの発熱量と快適なＣＰＵクロック周波数での操作環境のバランスを目指したものである。

ところで、例えば、オフィスに設置される様なＰＣにおいては、通常、オフィス内には様々な要因による騒音が存在し、ＰＣ自体が発生する騒音もその中に埋没する場合がある。
この様な時には、ＰＣからある程度の騒音が発生していたとしても、オペレータが快適に使用できるパフォーマンスを提供した方が得策である。つまり、快適なパフォーマンスを提供するため、ある程度、ＣＰＵクロック周波数を高くすることである。

しかし、クロック周波数が高くなれば、その分ＣＰＵからの発熱量が増えることになる。そのため、ＰＣが、温度による誤動作を起こさない範囲で、アプリケーションの快適な動作をすることが出来るように、システムクロック周波数を設定する必要がある。
また、逆に、オフィス内の騒音が少ない場合には、ＰＣから発生する騒音を極力抑えることが望ましい。

そこで、この実施形態では、ＰＣにマイクロフォン等に代表される集音装置を備えておき、リソース管理手段が、ＰＣ内で発生する騒音ばかりでなく、外部騒音による騒音を収集する。リソース管理手段がアクセスできるＣＰＵクロック周波数と収集できた騒音に関するデータベースにより、騒音レベルの許容範囲内でアプリケーション情報（快適な動作を行うクロック周波数、最低限必要なクロック周波数）に基づいてＣＰＵクロック周波数を変化させ、また、それに応じて、冷却ファンも制御する。

この実施形態に係るリソース管理手段について、図１２にその構成を示す。
図１２に示したリソース管理手段は、図１０に示したリソース管理手段をベースにしており、同じ部分には同じ符号を付してある。そして、図１２のリソース管理手段２には、マイクロフォン９がＰＣの近傍に配置されており、制御部２２が、マイクロフォン９で集音した騒音に関するデータを取得する。

図１３の第３管理テーブルに示されるように、騒音レベルに適したＰＣのシステムクロック周波数として、騒音レベル毎に、許容ＣＰＵクロック周波数を選定しておき、記憶部２１内に格納しておく。この許容ＣＰＵクロック周波数は、外部騒音レベル毎における、ＰＣが採りえる最大のクロック周波数となる。

マイクロフォン９で集音した騒音レベルに応じて、第３管理テーブルから該当する許容ＣＰＵクロック周波数を求める。外部騒音のレベルの高低に応じて、ＰＣのクロック周波数も変化し、例えば、外部騒音レベルが高くなれば、クロック周波数も高くなるため、ＰＣ自体が発生する騒音も増えることになる。

次に、図１２のリソース管理手段の動作について、図１４のフローチャートを参照して説明する。図１４のフローチャートでは、説明を簡単化するため、外部騒音に係る動作を中心に表しており、温度条件による図１１のフローチャートの動作に、図１４のフローチャートの動作を組み込むことができる。

先ず、マルチタスクで各アプリケーションの実行が開始されると、図１１のステップＳ５０１と同様に、リソース管理手段２は、実行に係わる各アプリケーションＡＰｎから快適動作のクロック周波数と最低限動作のクロック周波数とを取り出し、図６に示した第２管理テーブルを作成し、記憶する。そして、該テーブルに記憶したアプリケーションＡＰｎ毎のクロック周波数に基づいて、アプリケーションＡＰｎ毎に、この時のＰＣが採りえる最大のクロック周波数（３００MHz ）を基にして、最適動作のＣＰＵ使用率と最低限動作のＣＰＵ使用率とをそれぞれ求める（ステップＳ６０１）。

ここで、リソース管理手段２は、マイクロフォン９からＰＣの外部騒音を測定し（ステップＳ６０２）、この測定された外部騒音レベルに比較して、ＰＣ自体が発生する騒音レベルが許容範囲内であるかどうかが判断される（ステップＳ６０３）。

ＰＣ自体の発生する騒音レベルが許容範囲外である場合（Ｎ）には、外部騒音よりＰＣ自体の発生する騒音の方が大きいということであるので、ＰＣのシステムクロック周波数を下げる必要がある。そのため、最低限動作のクロック周波数を求め、そのクロック周波数をシステムクロックとして設定する（ステップＳ６０４）。

一方、ステップＳ６０３で、ＰＣ自体の発生する騒音レベルが許容範囲内である場合（Ｙ）には、外部騒音よりＰＣ自体の発生する騒音の方が小さいということであるので、ＰＣのシステムクロックを高くしても差し支えないということになる。そこで、記憶部２１に格納されている第３管理テーブルに基づいて、外部騒音が、快適に動作するＣＰＵクロック時の許容クロック周波数より高いかどうか判断される（ステップＳ６０５）。

外部騒音が、快適に動作するＣＰＵクロック時の許容クロック周波数に対応する騒音レベルより高い場合（Ｙ）には、快適に動作するクロック周波数でのシステムクロック周波数を求め、それをシステムクロックとして設定する（ステップＳ６０６）。

また、外部騒音が、快適に動作するＣＰＵクロック時の許容クロック周波数に対応する騒音レベルより低い場合（Ｎ）には、外部騒音に対する許容ＣＰＵクロックを求め、それをシステムクロックとして設定する（ステップＳ６０６）。

ステップＳ６０６又はステップＳ６０６の動作の後には、ステップＳ６０１及びステップＳ６０２に戻り、外部騒音のレベルに応じたシステムクロックを設定し直す動作に進む。

このように、本実施形態によれば、外部騒音を測定するようにしたので、外部騒音に応じて、誤動作を起こさない範囲で、アプリケーション情報（快適な動作を行うクロック周波数、最低限必要なクロック周波数）と騒音レベルに対応する許容クロック周波数に基づいてＣＰＵクロック周波数を変化させることができ、騒音条件下でも、アプリケーションを快適に使用できるパフォーマンスを提供できる。

以上説明したように、本発明によれば、ＰＣ等の情報処理装置のクロック制御において、実際のマルチタスクで実行される複数のアプリケーションからの要件と使用環境条件に応じて、クロック周波数の制御を行うことができる。

そのため、オペレータが快適にアプリケーションを操作できる範囲内でＣＰＵクロックを変化させることができ、情報処理装置の発熱量を抑え、安定したオペレーションが可能となる。

さらに、情報処理装置が、パフォーマンスに関するアプリケーション要件を満たせるのか、常にチェック可能であることから、オペレータは情報処理装置のアップグレードが必要な時期について、タイムリーにアラームを受けることができ、電源条件下では、バッテリ切れをも通知できる。

Claims (4)

1. 複数のアプリケーションを実行できる情報処理装置であって、
   前記各アプリケーションから読み取られた実行上必要なクロック周波数を、前記複数のアプリケーション毎に登録する記憶部と、
   前記記憶部に登録された前記各クロック周波数に基づいて、前記アプリケーション毎に、前記各アプリケーションを実行する前記情報処理装置が採りえる最大のクロック周波数に対する前記情報処理装置のＣＰＵ使用率を演算し、演算された前記アプリケーション毎の前記各ＣＰＵ使用率の総和と前記最大のクロック周波数との乗算に基づいて、前記情報処理装置のシステムクロック周波数を決定し、該システムクロック周波数を設定する制御部を含み、
   前記制御部は、前記決定されたシステムクロック周波数が、前記最大のクロック周波数を超えたとき、クロック周波数超過アラームを送出し、前記システムクロック周波数が前記最大のクロック周波数を超える頻度が増大する場合、前記情報処理装置のアップグレード必要性アラームを送出する情報処理装置。
2. 複数のアプリケーションを実行できる情報処理装置であって、
   前記各アプリケーションから読み取られた実行上必要なクロック周波数を、前記複数のアプリケーション毎に登録する記憶部と、
   前記記憶部に登録された前記各クロック周波数に基づいて、前記アプリケーション毎に、前記各アプリケーションを実行する前記情報処理装置が採りえる最大のクロック周波数に対する前記情報処理装置のＣＰＵ使用率を演算し、演算された前記アプリケーション毎の前記各ＣＰＵ使用率の総和と前記最大のクロック周波数との乗算に基づいて、前記情報処理装置のシステムクロック周波数を決定し、該システムクロック周波数を設定する制御部を含み、
   前記制御部は、前記決定されたシステムクロック周波数が、前記最大のクロック周波数を超える頻度が増大する場合、前記情報処理装置のアップグレード必要性アラームを送出する情報処理装置。
3. 複数のアプリケーションを実行するときに、前記各アプリケーションから、当該アプリケーションが実行上快適に動作する第１クロック周波数と、当該アプリケーションが動作上最低限必要な第２クロック周波数とを読み取り、前記複数のアプリケーション毎に登録し、
   登録された前記各クロック周波数に基づいて、前記アプリケーション毎に、前記各アプリケーションを実行する情報処理システムが採りえる最大のクロック周波数に対する前記情報処理システムにおけるＣＰＵ使用率を演算し、
   演算された前記アプリケーション毎の前記各ＣＰＵ使用率の総和と前記最大のクロック周波数との乗算に基づいて、前記情報処理システムのシステムクロック周波数を決定し、該システムクロック周波数を設定し、
   前記決定されたシステムクロック周波数が、前記最大のクロック周波数を超えたとき、クロック周波数超過アラームを送出し、
   前記システムクロック周波数が前記最大のクロック周波数を超える頻度が増大する場合、前記情報処理システムのアップグレード必要性アラームを送出することを実行させるプログラムを記録した記録媒体。
4. 複数のアプリケーションを実行するときに、前記各アプリケーションから、当該アプリケーションが実行上快適に動作する第１クロック周波数と、当該アプリケーションが動作上最低限必要な第２クロック周波数とを読み取り、前記複数のアプリケーション毎に登録し、
   登録された前記各クロック周波数に基づいて、前記アプリケーション毎に、前記各アプリケーションを実行する情報処理システムが採りえる最大のクロック周波数に対する前記情報処理システムにおけるＣＰＵ使用率を演算し、
   演算された前記アプリケーション毎の前記各ＣＰＵ使用率の総和と前記最大のクロック周波数との乗算に基づいて、前記情報処理システムのシステムクロック周波数を決定し、該システムクロック周波数を設定し、
   前記決定されたシステムクロック周波数が、前記最大のクロック周波数を超える頻度が増大する場合、前記情報処理システムのアップグレード必要性アラームを送出することを実行させるプログラムを記録した記録媒体。

Images