JP2008234191A

JP2008234191A - ハードウエアモニタ管理装置及びハードウエアモニタ機能の実行方法

Info

Publication number: JP2008234191A
Application number: JP2007071357A
Authority: JP
Inventors: Akira Iguchi; 晃井口
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2007-03-19
Filing date: 2007-03-19
Publication date: 2008-10-02
Also published as: US20080235700A1

Abstract

【課題】複数のモニタコンテキスト間の競合を解決し、かつ正確な性能解析を支援することができるハードウエアモニタ管理装置を提供する。
【解決手段】ハイパーバイザOS６は、複数のプロセスを並列に実行する複数の物理プロセッサの動作状態をモニタするハードウエアモニタ機能を設定するために、それぞれがモニタ動作条件と優先度の情報を含む複数のモニタコンテキストが設定されるモニタコンテキストテーブル５０を有する。ハイパーバイザOS６は、モニタ動作条件を満たす高い優先度のモニタコンテキストについては、ハードウエアモニタ機能を実行させてモニタデータを取得して、モニタ動作条件を満たす時間を示すタイミングデータと共に出力し、モニタ動作条件を満たすが低い優先度のモニタコンテキストについては、モニタ動作条件を満たす時間を示すタイミングデータを出力する。
【選択図】図１

Description

本発明は、ハードウエアモニタ管理装置及びハードウエアモニタ機能の実行方法に関し、特に、複数の物理プロセッサの動作状態をモニタするハードウエアモニタ管理装置及びハードウエアモニタ機能の実行方法に関する。

近年、１チップ上に複数のプロセッサコアを搭載するマルチコアプロセッサが開発され、そのマルチコアプロセッサの組み込まれた製品も、市場に登場してきている。マルチコアプロセッサは、各プロセッサコア（以下、単にコアともいう）及びプロセッサリソースを有効利用することにより、シングルコアプロセッサをはるかに超える性能を実現できるものである。しかし、その高い性能を得るためには、マルチコアプロセッサの機能を十分に使いきるようにソフトウエアのチューニングが必要となる。

また、プロセッサのハードウエアモニタ機能とは、プロセッサ内部の様々な状態変化を観察、カウント等するための機能である。この機能を用いることにより、プロセッサの特長に合わせた、ソフトウエアのチューニング、システムの性能測定、等が可能となる。基本的には１プロセッサにつき１つのハードウエアモニタ機能が設けられている。

ここで、従来のシングルコアプロセッサにおけるハードウエアモニタ機能の管理方法について簡単に説明する。まず、プロセス毎の性能情報を取得するために、ハードウエアモニタ機能の設定は、モニタしたいプロセスのコンテキスト、すなわちモニタコンテキストを指定することによって行われる。具体的には、モニタコンテキストの指定は、プロセッサ内部のレジスタの設定である。また、通常のハードウエアモニタ機能には、カウンタの数、等のリソースに制限があるため、多くのモニタデータを取得するには、ハードウエアモニタ機能の設定を変更して繰り返しプログラムを実行する必要がある。このリソース制限の問題を解決するために、測定されるデータ、すなわちモニタデータ、が不連続になることを許容するのであるが、モニタコンテキストを時分割でスケジューリングする方法がある。その方法として代表的なものに、PAPI（Performance API）のmultiplexing機能がある（例えば、非特許文献１参照）。

しかし、マルチコアプロセッサに、これらの手法をそのまま適用することはできなかった。それは、ハードウエアモニタ機能に対する、複数のモニタコンテキスト間の競合の問題があるからである。マルチコアプロセッサでは、異なるコア上で同時に複数のプロセスが実行状態になる。そのような実行状態のときに各プロセスが異なるモニタコンテキストを持つ場合、ハードウエアモニタ機能の利用権についての競合が発生するためである。

この競合を解決するために、時分割でモニタコンテキストをスケジューリングするようにしても良いが、その場合、取得されるモニタデータは、不連続なデータとなってしまう。正確な性能解析を目的とする場合、取得された不連続なデータをどのように解釈すればよいかは、大きな課題となってしまう。
PAPI ユーザ・ガイド（３．５．０版）（PAPI USER’S GUIDE Version 3.5.0）（URL：http://icl.cs.utk.edu/papi/index.html）

そこで、本発明は、以上の問題に鑑みてなされたものであり、複数のプロセスを並列に実行する複数の物理プロセッサの動作状態をモニタする場合に、複数のモニタコンテキスト間の競合を解決し、かつ正確な性能解析を支援することができるハードウエアモニタ管理装置及びハードウエアモニタ機能の実行方法を提供することを目的とする。

本発明の一態様によれば、複数のプロセスを並列に実行する複数の物理プロセッサの動作状態をモニタするハードウエアモニタ機能を設定するために、それぞれがモニタ動作条件と優先度の情報を含む複数のモニタコンテキストが設定されるモニタコンテキストテーブルと、前記モニタ動作条件を満たす１以上のモニタコンテキストの中で、前記優先度に基づいて決定された前記ハードウエアモニタ機能を設定するモニタコンテキストについては、前記ハードウエアモニタ機能を実行させてモニタデータを取得して、前記モニタ動作条件を満たす時間を示す第１の時間データと共に出力し、前記モニタ動作条件を満たす前記１以上のモニタコンテキストの中で、前記優先度に基づいて決定された前記ハードウエアモニタ機能を設定しないモニタコンテキストについては、前記モニタ動作条件を満たす時間を示す第２の時間データを出力するハードウエアモニタ管理部と、を有するハードウエアモニタ管理装置を提供することができる。

本発明の一態様によれば、複数のプロセスを並列に実行する複数の物理プロセッサの動作状態をモニタするハードウエアモニタ機能を設定するために、それぞれがモニタ動作条件と優先度の情報を含む複数のモニタコンテキストが設定されるモニタコンテキストテーブルを設け、前記モニタ動作条件を満たす１以上のモニタコンテキストの中で、前記優先度に基づいて決定された前記ハードウエアモニタ機能を設定するモニタコンテキストについては、前記ハードウエアモニタ機能を実行させてモニタデータを取得して、前記モニタ動作条件を満たす時間を示す第１の時間データと共に出力し、前記モニタ動作条件を満たす前記１以上のモニタコンテキストの中で、前記優先度に基づいて決定された前記ハードウエアモニタ機能を設定しないモニタコンテキストについては、前記モニタ動作条件を満たす時間を示す第２の時間データを出力するハードウエアモニタ機能の実行方法を提供することができる。

本発明によれば、複数のプロセスを並列に実行する複数の物理プロセッサの動作状態をモニタする場合に、複数のモニタコンテキスト間の競合を解決し、かつ正確な性能解析を支援することができるハードウエアモニタ管理装置及びハードウエアモニタ機能の実行方法を提供することができる。

以下、図面を参照して本発明の実施の形態を説明する。
（第１の実施の形態）
まず、図１に基づき、本発明の第１の実施の形態に係わるシステムの構成を説明する。図１は、本実施の形態に係わるハードウエアモニタ機能を有するマルチコアプロセッサシステムの構成を示すブロック図である。
本実施の形態では、ハイパーバイザオペレーティングシステムが、複数の論理パーティションについて設定された複数のハードウエアモニタコンテキストを管理する。

マルチコアプロセッサシステム１０１は、いわゆる３層構造を有するコンピュータシステムであり、例えばパーソナルコンピュータ（PC）等である。３層中、最下位層１０２は、マルチコアプロセッサであるプロセッサ１、主メモリ２等から構成されるハードウエア層である。一般的には様々なハードウエアデバイスがこの層１０２に存在するが、説明を簡単にするために省略されている。プロセッサ１には、複数の物理的なコアプロセッサ（以下、物理コアという）３、入出力部（以下、I/Oユニットという）４等と共に、ハードウエアモニタ機能部（図１ではHWモニタ機能部）５が備わっている。物理コア３は、N個（Nは２以上の整数）ある。プロセッサ１は、それぞれが物理プロセッサである、複数の物理コア３により、複数のプロセスを並列に実行することができる。ハードウエアモニタ機能部５の機能については後述する。なお、本実施の形態は、1つのプロセッサ（すなわちプロセッサ１）に、1つのハードウエアモニタ機能部が設けられている場合である。

中位層１０３には、ハイパーバイザオペレーティングシステム（以下、ハイパーバイザOSという）６が存在する。ハードウエアモニタ管理装置を構成するハイパーバイザOS６は、仮想マシンモニタ（VMM）とも呼ばれる。ハイパーバイザOS６の機能は、後述する上位層１０４の各論理パーティション上のゲストオペレーティングシステム（以下、ゲストOSという）に対して物理的なハードウエアを隠蔽し、仮想ハードウエアを提供することである。各論理パーティションの状態は、ハイパーバイザOS６がコンテキストとして管理する。ハイパーバイザOS６を利用する利点としては、単一システム上で複数のゲストOSを同時に動作させることができるので、ａ）各ゲストOSの長所を併せ持つシステムを構築できること、ｂ）物理的なハードウエアの違いを隠蔽できること、ｃ）各ゲストOSの動作エラーがシステム全体に影響しないこと、等々が挙げられる。パイパーバイザOS６は、スケジューラ部としての論理コアスケジューラ６ａを含む。

最上位層１０４には、1つ以上の論理パーティション７が存在し、論理パーティション毎にゲストOS８及びアプリケーションプログラム（以下、単にアプリケーションという）９が動作する。本実施の形態では２つのパーティションAとBがある。各論理パーティション７は、１以上の論理的なコアプロセッサ（以下、論理コアという）１０を有する。図１では、論理パーティションAには、論理コア１０は、論理コアAが（ｍ＋１）個（ｍは２以上の整数）あり、論理パーティションBには、論理コア１０は、論理コアBが（ｎ＋１）個（ｎは２以上の整数）ある。各論理コア１０が、ハイパーバイザOS６の論理コアスケジューラによって、各物理コア３にディスパッチされることにより、各論理パーティション７内の、ゲストOS８及びアプリケーション９のプログラムあるいはプロセスは動作することができる。

すなわち、各パーティション７内では、複数の論理コア１０は、ゲストOS８に対しては、複数の物理コア３として認識されており、ハイパーバイザOS６が、複数のパーティション７のコンテキストを管理することによって、複数のプロセスが、プロセッサ１上で動作可能となっている。

次に、ハードウエアモニタ機能部５の機能について説明する。図２は、ハードウエアモニタ機能部５の機能を説明するために、ハードウエアモニタ機能部５と上位のOSとの関係を説明するための図である。ハードウエアモニタ機能部５は、プロセッサ１のリソースであり、プロセッサ１を構成する各物理コア３、プロセッサ１の外部との通信を行うI/Oユニット４、物理コア内のメモリ管理ユニット（MMU）、等の各機能ユニット内で発生したイベントを取得し、あるいはカウントする。発生するイベントとしては、例えば、実行プログラムのストール、キャッシュミス、バストラフィック等であり、このようなイベントが発生すると、それぞれに対応する所定のフラグを立てる、回数をカウントする、等が行われる。フラグデータ、及びカウントされたデータは、それぞれの専用レジスタへのアクセスによって取得できる。さらに、カウンタのオーバーフローによって割り込みを発生させる機能を実装するようにしてもよい。すなわち、ハードウエアモニタ機能部５は、プロセッサ１内の各種ハードウエアの動作状態をモニタする機能を有する。

ハードウエアモニタ機能部５の機能の設定は、ハードウエアモニタ管理装置としてのハイパーバイザOS６によって行われる。具体的には、ソフトウエア開発者等であるユーザが、コンピュータの画面を見ながらキーボード、マウス等の入力装置を利用して、ハードウエアモニタ機能の設定を行う。あるいは、ユーザが、実行プログラム中にその設定内容を書き込むことによって、ハードウエアモニタ機能の設定を行う。ユーザによって設定された内容は、ハイパーバイザOS６によって、プロセッサ１内のハードウエアモニタ機能部５に設定される。これは、各論理パーティション７上のプログラムからは、直接ハードウエアモニタ機能部５にアクセスすることはできず、ハイパーバイザOS６への要求によってのみハードウエアモニタ機能部５に対する操作が可能だからである。
また、ハードウエアモニタ機能部５は、本実施の形態では１つであり、また、モニタするレジスタ数等も限られている。すなわち、ハードウエアモニタ機能部５の各リソース数は限られている。
さらに、プロセッサ１の物理的なハードウエアは、ハイパーバイザOS６によって隠蔽されているため、複数の論理パーティション７からの複数のハードウエアモニタ設定要求に対して適切に対応する必要がある。具体的には、例えば、パーティションAからのハードウエアモニタ機能部５に対する設定の内容と、パーティションBからのハードウエアモニタ機能部５に対する設定の内容が異なるため、このような異なる設定要求に対して適切に対応する必要がある。
通常のハイパーバイザOS６は、論理コアと物理コアの対応付け（ディスパッチ）等の通常の機能だけであるが、本実施の形態のハイパーバイザOS６は、ハイパーバイザOSとしての通常の機能に加えて、ハードウエアモニタ管理装置の機能として、各ハードウエアモニタコンテキストの設定機能と、ハードウエアモニタ機能部５に対する操作機能とを有する。ハードウエアモニタコンテキスト、すなわちモニタコンテキスト、は、モニタ要求に係るレジスタに関する設定情報であり、その設定情報に従って、ハードウエアモニタ機能部５は、レジスタのデータをモニタする。ハイパーバイザOS６が、モニタコンテキストの設定を行う。また、ハードウエアモニタ機能部５に対する操作は、ハードウエアモニタ管理部としての論理コアスケジューラ６ａによって、所定のタイミングで行われる。
以上のように、ハイパーバイザOS６は、設定された複数のモニタコンテキストに従って、ハードウエアモニタ機能部５に対する操作（すなわち実行管理）を、所定のスケジュールによって決まった所定のタイミングで行う。よって、ハイパーバイザOS６の論理コアスケジューラ６ａは、後述するように、プロセッサ１の動作状態を常時監視し、監視の各フェーズで、どのモニタコンテキストのモニタデータを取得するか等の処理を実行する、ハードウエアモニタ管理部である。

これらについて以下で説明する。

図３は、設定されるモニタコンテキストの内容を示す図である。各モニタコンテキスト３０は、大きく分けて５つの項目のデータ、コンテキスト管理情報３１、ハードウエアモニタ設定情報３２と、モニタ動作条件情報３３と、優先度情報３４と、タイミングデータ３５とを有する。
コンテキスト管理情報３１は、各モニタコンテキストの識別子、有効あるいは無効を示す有効・無効フラグ、取得したデータであるモニタデータを格納するバッファの情報、モニタコンテキストの設定要求を行った論理パーティションに関する情報、などを含む。モニタデータを格納するバッファの情報は、例えば、モニタデータを、パーティション毎に、主メモリ２の、どのバッファ領域に格納するかを示す情報である。コンテキスト管理情報３１は、主にモニタコンテキストの検索あるいは削除、カウンタのオーバーフロー時あるいはデータ格納用バッファのオーバーフロー時のイベント通知に利用される。

ハードウエアモニタ設定情報３２とは、ハードウエアモニタ機能部５を制御するためのレジスタに設定する情報である。ハードウエアモニタ設定情報３２の代表的な設定項目としては、取得するイベントの種類、カウンタの振る舞い等の項目である。本来のハードウエアレジスタの設定では、物理的な値、すなわち物理コア番号、を指定する必要があるが、論理パーティションは論理的な値、すなわち論理コア番号が指定される。よって、本実施の形態では、論理パーティションについての論理的な値を設定することが許可され、ハイパーバイザOS６が実行時に、論理的な値を適切な物理的な値に変換する。

モニタ動作条件情報３３は、ハードウエアモニタ機能部５の機能が有効となる条件を、各論理コアの実行状態に関する論理演算式（ここでは、論理積（AND）と論理和（OR）の少なくとも１つ）で表現された、モニタデータを取得する条件を設定するための設定項目の情報である。論理コアが実行状態にあるときとは、その論理コアが物理コアに割り当てられているときである。よって、複数の論理コアのそれぞれの実行状態は、論理演算式で表現されるが、ある論理コアが物理コアに割り当てられているときがその論理コアの実行状態である。

マルチコアプロセッサのハードウエアモニタ機能に対する新たな要求として、様々な単位あるいは範囲での性能測定が考えられる。一般に、ハードウエアモニタ機能を利用して得られる情報は、プロセッサ全体としての情報である。よって、このようなプロセッサ全体としての情報としてのモニタデータを取得したいという要求もある。しかし、他方では、プロセス単位で、あるいはプロセスが動作するコア単位で、ソフトウエアプログラムを開発するユーザもおり、このようなユーザからは、詳細な性能情報を得るために、特定コア動作時のモニタデータ、複数コアの組み合わせに関するモニタデータ、等を取得したいという要求もあり得る。

本実施の形態によれば、モニタコンテキスト３０のモニタ動作条件情報３３において論理演算式を利用することにより、種々の要求に対するモニタデータの取得をすることができる。
例えば、ユーザは、特定の論理コア、あるいは特定のプロセスの動作に直接関係するモニタデータのみを取得するように、モニタ動作条件情報３２を設定することができる。
また、ある特定の論理パーティションに属する全ての論理コアの実行状態を論理和（OR）で結合した論理演算式で指定することによって、ユーザは、その特定の論理パーティションに関係するモニタデータのみを取得するように、モニタ動作条件情報３３を設定することもできる。その結果、論理パーティション単位の性能評価を行うことができる。

さらに、システム全体の性能評価を行うために、常に条件が成立するような特別な値も用意することもできる。例えば、全てのモニタコンテキストのデータを取得するために、所定のレジスタについて「１」のような値を設定することによって、ユーザは、所定のレジスタについては、全てのモニタデータを取得するように設定することも可能である。以上のように、このようなモニタ動作条件情報により、様々な単位、あるいは範囲での性能測定要求に対応したモニタデータの取得をすることができる。

本実施の形態において論理式においてANDとORのみを利用する理由は、条件の設定処理及びその条件の確認処理を簡単にするためである。単純な論理式を使うことにより、ハイパーバイザOS６への設定のためのインタフェースが簡単になり、設定された条件の確認も高速化することができる。より複雑な論理式を用いることも可能であるが、もし複雑な論理式を用いた場合、条件の確認処理のオーバヘッドが大きくなる。本実施の形態では、論理コアのスイッチ時に毎回条件確認を行うので、このオーバヘッドは許容できないとして、複雑な論理式は用いられていない。

すなわち、モニタ動作条件として、AND条件、OR条件、あるいは常に成立する特殊な条件を利用することにより、種々の条件を簡潔に記述することができる。さらに、注目するプロセス群に関する論理コアの組み合わせをモニタ動作条件としてモニタコンテキストに付与することにより、論理コア単位の性能情報、複数の論理コアの性能情報、あるいはシステム全体の性能情報を取得することができる。言い換えると、様々な単位あるいは範囲の性能情報を取得することができる。

従来であれば、プロセッサ全体としての情報から特定コア動作時の情報の切り出しは、ソフトウエアを開発する者等が、取得されたモニタデータを直接見て行うため、困難な場合が多かったが、以上のようなモニタ動作条件を設定することにより、マルチOSでマルチコアプロセッサが動作している場合であっても、種々の単位あるいは範囲で、ハードウエアモニタ機能を実行することが可能となる。

優先度情報３４は、複数のモニタコンテキスト間で同時にモニタ動作条件が成立した場合に発生する、ハードウエアモニタ機能部５の機能利用の競合を解決するための、モニタコンテキストについての優先度に関する情報である。このような競合時には、高優先度のモニタコンテキストを有効として、高優先度のモニタコンテキストのデータがハードウエアモニタ機能部５によってモニタされるため、重要なモニタコンテキストにはより高い優先度が設定され、高優先度のモニタコンテキストについては、連続したモニタデータが取得できる。優先度の情報は、ユーザが各目的に応じて設定する。

タイミングデータ３５は、モニタ動作条件の成立及び不成立時に記録される時間データである。タイミングデータ３５は、取得したモニタデータの信頼性判断をサポートするために利用される。時間データを利用することにより、取得したモニタデータは、最終的には図４に示すようなフォーマットで得ることができる。従って、モニタコンテキストの優先度によって、モニタデータは、モニタ動作条件の成立及び不成立時のモニタコンテキストの優先度に応じて、２種類のフォーマットのいずれかで記録される。

図４は、複数のモニタコンテキスト間で、あるフェーズにおいて同時にモニタ動作条件が成立した場合に、最も優先度の高いモニタコンテキストについて、バッファに格納されるモニタデータのフォーマットを示す図である。図５は、複数のモニタコンテキスト間で、あるフェーズにおいて同時にモニタ動作条件が成立した場合に、優先度の低いモニタコンテキストについて、バッファに格納されるモニタデータのフォーマットを示す図である。

複数のモニタコンテキスト中の最高優先度のコンテキストについては、図４に示すように、新たにモニタ動作条件が成立した時点のタイミングデータ４０とStartフラグ４１を記録することによって、ハードウエアモニタ機能部５の機能の利用が開始されたことを示すように、モニタデータ４２が記録される。その後にモニタ動作条件が不成立になった時点で、モニタコンテキストのデータ４２と、その時点のタイミングデータ４０と、Stopフラグ４３を対応する所定のバッファに記録することによって、ハードウエアモニタ機能部５の機能の利用が終了したことを示すように、モニタデータ４２が記録される。

その最高優先度ではないモニタコンテキストについては、図５に示すように、新たにモニタ動作条件が成立した時点で、あるいは優先度の高い他のモニタコンテキストにハードウエアモニタ機能の利用権が奪われた時点で、その時点のタイミングデータ４０とFake_Startフラグ４４を記録することによって、不連続データの開始であることを示すデータが記録される。その後にモニタ動作条件が不成立になった時点で、あるいは優先度の高い他のモニタコンテキストがなくなり、ハードウエアモニタ機能部５の機能の利用権を取得した時点で、その時点のタイミングデータ４０とFake_Stopフラグ４５を記録することによって、不連続データの終了であることを示すデータが記録される。よって、モニタ動作条件を満たす１以上のモニタコンテキストの中で、優先度情報に基づいて決定されたハードウエアモニタ機能を設定しないモニタコンテキストについては、そのモニタ動作条件を満たす時間を示す時間データが、Fake_Startフラグ４４とFake_Stopフラグ４５と共に出力され、記録される。

タイミングデータ４０としては、リアルタイムクロックの値等の、ハードウエアモニタ機能が実施されるシステムに応じた適切な時間データが利用される。また、Startフラグ４１とStopフラグ４３は、常に対で記録される。さらに、Fake_Startフラグ４４とFake_Stopフラグ４５も、常に対で記録される。

このように、モニタデータ４２とともに、時間データであるタイミングデータ４０、モニタ動作状態データ（Start/Stopフラグ４１，４３及びFake_Start/Fake_Stopフラグ４４，４５）が出力されて記録される。これらの記録されたデータを用いることにより、その記録されたデータにおいて低優先度のコンテキストに関するモニタデータが不連続になるという問題に対して、取得されたデータが本来取得したいデータの何％に相当するかというカバレッジの計算ができる。すなわち、これらの記録されたデータは、モニタデータの信頼性を判断する材料を得るためのデータとして利用することができる。

従って、複数のモニタコンテキスト中、１つのモニタコンテキストだけについてモニタ動作条件が成立した場合には、その１つのモニタデータだけが記録される。しかし、複数のモニタコンテキスト間で同時にモニタ動作条件が成立した場合には、最も優先度の高いモニタコンテキストのモニタデータが図４に示すフォーマットで記録される。その場合、他の優先度の低いモニタコンテキストのモニタデータは取得されないが、図５に示すように、モニタ動作条件が成立した時点のタイミングデータと、モニタ動作条件が不成立になった時点の、あるいは優先度の高い他のモニタコンテキストがなくなり、ハードウエアモニタ機能部５の機能の利用権を取得した時点のタイミングデータとが、それぞれ、所定の指標（ここでは、Fake_StartとFake_Stopの両フラグ）とともに、バッファに出力されて記録される。

よって、ユーザは、以上のように記録されたモニタコンテキストに関するデータを見ることによって、各モニタコンテキストの不連続になった時点、不連続データの回数あるいは量を把握することができる。

上述したモニタコンテキスト３０は、図６のようなテーブルで優先度順に管理される。図６は、モニタコンテキストテーブルの構成を示す図である。図６に示すように、モニタコンテキストテーブル５０には、優先度順に複数のモニタコンテキスト３０が記録されている。複数のモニタコンテキストを優先度順で管理する理由は、論理コアスイッチ時（物理コアのディスパッチの切り替わり時）におけるモニタ動作条件の確認処理に伴うオーバヘッドを最小化するためである。本実施の形態では、論理コアスケジューラ６ａが、モニタコンテキストテーブル５０を有する。

ハイパーバイザOS６が、より具体的にはハイパーバイザOS６のコアスケジューラが、モニタコンテキストテーブル５０の全てのモニタコンテキスト３０の内容を優先度の高い順に走査することによって、各モニタコンテキスト３０についてモニタ動作条件情報３３に記述されたモニタ動作条件が成立しているか否かをチェックする。その走査の結果、モニタ動作条件が成立しているモニタコンテキストの中で最高優先度のモニタコンテキストについて、図４に示すフォーマットでモニタデータ４２が記録される。モニタ動作条件が成立している複数のモニタコンテキスト中で、優先度情報３４の示す優先度が最高優先度のモニタコンテキストの優先度より低いモニタコンテキストについては、図５に示すフォーマットでデータが記録される。

本実施の形態では、基本的には全モニタコンテキストのタイミングデータを取得するためには全テーブルエントリ（すなわち全モニタコンテキスト）を走査する必要があるが、タイミングデータがすべてについて必要ない場合には、優先度の高い１以上のエントリについてだけモニタ動作条件が成立した時点で走査を終了するようにしてもよい。

モニタコンテキストの登録時には、各論理パーティション７についてのモニタコンテキスト３０の設定要求が発行され、ハイパーバイザOS６が、そのモニタコンテキスト３０の優先度に従ってモニタコンテキストテーブル５０中に適切なテーブルエントリとして登録する。各論理パーティション７について、複数のモニタコンテキスト３０を登録できるが、モニタコンテキスト数が増えると、論理コアスケジューラにおける処理負荷が増大するため、許容できるオーバヘッド量を考慮して、モニタコンテキストテーブル５０に登録可能な最大コンテキスト数を制限するようにしてもよい。

モニタコンテキストの削除時には、対応する論理パーティション７についてのモニタコンテキスト３０の識別子を指定することによって、ハイパーバイザOS６はその識別子と一致するテーブルエントリを削除する。

次に、ハードウエアモニタ機能部５についての機能が追加された論理コアスケジューラの処理について説明する。図７は、論理コアスケジューラの処理の流れの例を示すフローチャートである。ハードウエアモニタ管理部としての論理コアスケジューラは、常時実行しているが、その実行毎に、すなわち実行の各フェーズで、図７の処理を実行する。
最初に、論理コアスケジューラ６ａは、通常の論理コアスケジューラと同様、次フェーズでの論理コアの動作状態を決定する（ステップS1）。すなわち、次のフェーズで動作する論理コアが決定される。

次に、論理コアスケジューラ６ａは、図６のモニタコンテキストテーブル５０の全モニタコンテキスト３０を優先度順に走査し、各モニタ動作条件の確認を行う（ステップS2）。モニタ動作条件が成立したモニタコンテキスト３０の中で、最高優先度のモニタコンテキストではなく、かつ、現フェーズまでにFake_Startフラグ４４を記録していないモニタコンテキスト３０については、論理コアスケジューラ６ａは、タイミングデータ４０とFake_Startフラグ４４を出力して、対応するバッファに記録する。また、モニタ動作条件が成立しないモニタコンテキスト３０の中で、Fake_Startフラグ４４の記録後に未だFake_Stopフラグを記録していないモニタコンテキスト３０については、論理コアスケジューラは、タイミングデータ４０とFake_Stopフラグ４５を出力して、対応するバッファに記録する。

全てのモニタコンテキスト３０について、ステップS2の確認処理が終了したか否かが判断され（ステップS3）、全てのモニタコンテキストについて確認処理が終了していない場合は、ステップS3でNOとなり、処理はステップS2に戻る。全てのモニタコンテキスト３０について、ステップS2の確認処理が終了した場合は、ステップS3でYESとなり、モニタ動作条件が成立したモニタコンテキスト３０が有るか否かの判断が行われる（ステップS4）。

ステップS2における走査処理において、それぞれのモニタ動作条件が成立する１以上のモニタコンテキスト３０が検出されたとする。その場合、ステップS4でYESとなり、その条件が成立したモニタコンテキスト３０の中で最高優先度のものが現在有効なコンテキスト（現在最高優先度のモニタコンテキストとしてハードウエアモニタ機能部５の機能を使用しているモニタコンテキスト）と一致するか調べ、モニタコンテキストの変更が必要か否かの確認が行われる（ステップS5）。

モニタコンテキストの変更が必要な場合は、ステップS5でYESとなり、論理コアスケジューラ６ａは、モニタ動作を終了し、現在のモニタデータ４２を対応するバッファに格納する(ステップS6)。モニタデータ４２の格納後、論理コアスケジューラは、タイミングデータ４０とStopフラグ４３の記録を行う（ステップS7）。

データの格納後、論理コアスケジューラ６ａは、モニタデータを取得するモニタコンテキスト３０を切り替える（ステップS8）。このとき、モニタコンテキスト３０の論理情報（論理コア番号等）を物理情報（物理コア番号等）へ変換してから、ハードウエアモニタ機能が設定される。その後、Nextフラグは１に設定される（ステップS9）。ステップS9の処理は、次フェーズに入る前にモニタ動作を開始させるようにするためである。モニタコンテキスト３０の変更が必要ない場合は、ステップS5でNOとなり、すでにその変更されないモニタコンテキスト３０についてモニタ動作は継続して行われているので、Nextフラグは０に設定される（ステップS10）。

一方、ステップS2における走査処理において、モニタ動作条件が成立するコンテキストが見つからなかった場合は、モニタ動作を停止させる必要がある。従って、その場合は、ステップS4でNOとなり、論理コアスケジューラ６ａは、現在のモニタ動作の状態をチェックし、モニタ動作が行われているか否かをチェックする（ステップS11）。

モニタ動作中の場合は、論理コアスケジューラ６ａは、そのモニタ動作を終了し、モニタデータを対応するバッファに格納する（ステップS12）。モニタデータの格納後、論理コアスケジューラ６ａは、タイミングデータ４０とStopフラグ４３の記録を行う（ステップS13）。ステップS12とS13の処理は、ステップS6とS7の処理と同じである。モニタ動作が停止している場合は、ステップS11でNOとなり、ステップS12とS13の処理は行われないで、処理は、ステップS10に移行し、Nextフラグが０に設定される。

その後、論理コアスケジューラ６ａは、通常の論理コアスケジューラと同様の、論理コアコンテキストの切り替えを行う（ステップS14）。最後にNextフラグが１であるか否かの確認が行われ（ステップS15）、Nextフラグが１であれば、ステップS15でYESとなり、次フェーズで有効となるモニタコンテキストのタイミングデータ４０とStartフラグ４１の記録を行う（ステップS16）。なお、現フェーズまでにFake_Startフラグ４４が記録されている場合は、Startフラグ４１の前にFake_Stopフラグ４５が記録される。そして、論理コアスケジューラ６ａは、ハードウエア機能部５からのモニタデータの取得をするべく、モニタ動作を開始させる（ステップS17）。

なお、図７では、ステップS6,S12において、モニタ動作の終了が行われている。すなわち、論理コアスケジューラ６ａの処理中におけるモニタ動作が許されている。しかし、性能測定の目的によっては、モニタコンテキストの処理の影響を受けているモニタデータを取得したくないという要求もあり得る。従って、そのような場合には、ステップS6,S12において、モニタ動作の終了をするのではなく、ステップS1の前に、モニタ動作中か否かを判定する処理を設け、その判定の結果、モニタ動作中の場合は、モニタ動作を終了する処理を設けるようする。さらに、ステップS4において、モニタ動作条件が成立したモニタコンテキストが検出された場合は、Nextフラグを常に１に設定し、図７の処理の最後においてモニタ動作を開始する。

このように、図７の論理コアスケジューラの処理の最初と最後において、モニタ動作の終了と開始を行うようにすることによって、モニタコンテキストについての処理の影響を受けたモニタデータを取得することを回避することができる。

ここまで、本実施の形態にかかるシステムの構成と主要な構成要素について説明を行った。
次に、システム動作時の状況の例を示し、上述した機能がどのように動作するかについて説明する。図８は、システム動作時の物理コアの状態、及びハードウエアモニタ機能の動作状態の例を説明するための図である。ここでは、説明を簡単にするために、プロセッサ１は、３つの物理コアP_x,P_y,P_zを有し、上位層には２つの論理パーティションA、Bが存在し、それぞれが論理コアA0,..Amと、B0,..,Bnとを有する場合で説明する。モニタコンテキストとして、論理パーティションA、Bのそれぞれについて、モニタコンテキストA、Bが設定されている。

図９は、モニタコンテキストテーブルの内容の例を簡単化して示した図である。図９に示すモニタコンテキストが、モニタコンテキストテーブル５０Aに設定されているとする。図９に示すように、モニタコンテキストAは、コンテキストBよりも優先度が高く設定されている。さらに、モニタコンテキストAでは、論理コアA0とA1が同時に実行していることが、モニタ動作条件である。モニタコンテキストBでは、論理コアB0とB1のいずれかが実行していることが、モニタ動作条件である。対象イベントのデータは、モニタコンテキストAでは、論理コアA0のデータであり、モニタコンテキストBでは、論理コアB0のデータである。

これらの論理コア及びモニタコンテキストに基づいて、ハイパーバイザOS６上の論理コアスケジューラ６ａが、図７に示す処理手順に従って処理した結果が図８に示されている。

図８では、上段に、３つの物理コアP_x,P_y,P_zに対する論理コアのディスパッチ状態が示されている。その中段に、各時点での論理コアの組み合わせに対する、モニタコンテキストA,Bについて、モニタ動作条件の成立と不成立が示されている。論理コアの組み合わせによっては、図８のように複数のモニタコンテキストにおいて同時に条件が成立する場合がある。その場合、図８に示すように、モニタコンテキストの優先度によって、次に有効となるモニタコンテキストが決定される。図８ではコンテキストAの方がコンテキストBよりも優先度が高いため、同時に条件が成立する２箇所ではコンテキストAが選択されている。

また、論理コア番号と物理コア番号との対応はシステム動作時に動的に決定される。そのため、モニタコンテキストでは、論理コア番号を使って対象イベントを設定し、論理コアスケジューラ６ａが動的に物理コア番号に変換する。図８のハードウエアモニタの状態の下には、実行時の論理コアと物理コアの対応に従って、対象イベントが変更されている様子が示されている。

より具体的に説明する。図８に示すように３つの物理コアP_x,P_y,P_zが動作したとする。時点t0からt1では、モニタコンテキストAのモニタ動作条件が成立し、モニタコンテキストBのモニタ動作条件は不成立である。従って、時点t0からt1では、モニタコンテキストAの対象イベントである論理コアA0の物理コアP_xのモニタデータが記録される。

時点t1からt2では、モニタコンテキストAのモニタ動作条件が成立し、モニタコンテキストBのモニタ動作条件も成立している。しかし、優先度は、モニタコンテキストAの方が高いので、時点t1からt2でも、モニタコンテキストAの対象イベントである論理コアA0の物理コアP_xのモニタデータが継続して記録される。

時点t2からt3では、モニタコンテキストAのモニタ動作条件は不成立であり、モニタコンテキストBのモニタ動作条件が成立している。従って、時点t2からt3でも、モニタコンテキストBの対象イベントである論理コアB0の物理コアP_yのモニタデータが記録される。

時点t3からt4では、モニタコンテキストAのモニタ動作条件は不成立であり、モニタコンテキストBのモニタ動作条件も不成立である。従って、時点t3からt4では、モニタデータの記録は、無効すなわちディスエイブルとなり、行われない。

時点t4からt5では、モニタコンテキストAのモニタ動作条件が成立し、モニタコンテキストBのモニタ動作条件も成立している。ここでも、優先度は、モニタコンテキストAの方が高いので、時点t4からt5では、モニタコンテキストAの対象イベントである論理コアA0の物理コアP_yのモニタデータが記録される。

時点t5からt6では、モニタコンテキストAのモニタ動作条件は不成立であり、モニタコンテキストBのモニタ動作条件が成立している。従って、時点t5からt6では、モニタコンテキストBの対象イベントである論理コアB0の物理コアP_xのモニタデータが記録される。

図１０と図１１は、図８のような実行例の結果、各モニタコンテキストのモニタデータ格納用のバッファが最終的にどうなるか示す図である。図１０は、モニタコンテキストAについてバッファの内容の例を示す図である。図１１は、モニタコンテキストBについてのバッファの内容の例を示す図である。図１０に示すように、モニタコンテキストAのバッファでは、Startフラグ４１とStopフラグ４３しか存在せず、モニタ動作条件成立時に常にモニタデータ４２が記録されている。一方、コンテキストBのバッファには、図１１に示すように、Fake_Startフラグ４４とFake_Stopフラグ４５が存在し、その期間はモニタデータ４２が取得できていない。しかし、タイミングデータ４０を利用すれば、取得したモニタデータのカバレッジが自動であるいはマニュアルで計算することができ、不連続データの信頼性を判断する材料として利用できる。

以上のように、本実施の形態によれば、マルチコアプロセッサにおいて有効なハードウエアモニタ機能管理を実現するために、複数のハードウエアモニタコンテキスト間の競合を調停するために、モニタコンテキストは、要素として優先度情報を有している。その結果、ユーザが取得したい、重要なモニタデータについては、連続して取得することができる。

さらに、低い優先度のモニタコンテキストについては、ハードウエアモニタ機能の時分割利用によってモニタデータが不連続になってしまう問題に対して、本実施の形態では、不連続データの信頼性を判断することができるようにするために、モニタコンテキストの切り替え時にタイミングデータを記録し、不連続データの解析をサポートするができるようにしている。

さらに、本実施の形態では、様々な単位あるいは範囲のモニタデータ取得要求に応えるために、モニタコンテキストは、その要素としてモニタ動作条件情報を有している。
従って、本実施の形態によれば、ハードウエアモニタ機能に対する競合の解決、不連続データの解析のサポート、及び、様々な単位あるいは範囲のデータ取得要求への対応を実現することができる。

次に上述した実施の形態の変形例を説明する。
上述した実施の形態では、ハイパーバイザOS６が、具体的には論理コアスケジューラ６ａが、モニタコンテキストの設定、ハードウエアモニタ機能部の操作等を行っていたが、論理パーティションと論理コアを有さない場合でも、上述したようなハードウエアモニタ機能を実現することができる。

具体的には、上述した実施の形態では、ハイパーバイザOS６を利用して、ハイパーバイザOS６がプロセッサ１のハードウエアモニタ機能を管理する場合に、ハードウエアモニタ機能の設定に関して、各論理パーティションには論理的な値の設定を許し、ハイパーバイザOS６の論理コアスケジューラ６ａが実行時に対応する物理的な値に変換することにより、ハードウエアの仮想化に対応している。第１の変形例では、ハイパーバイザOSが存在しない、すなわち各プロセスが持つハードウエアモニタコンテキストを、ハードウエアモニタ管理装置としてのOSが管理する。

図１２は、本実施の形態の第１の変形例に係るシステムの構成を示すブロック図である。マルチコアのプロセッサ１の上位にはOS９０が存在し、OS９０の上で複数のプロセス、ここではＭ個（Ｍは、２以上の整数）９１が動作している。そして、中位層１０３ａのOS９０が、上位層１０４ａの複数のプロセス９１のコンテキストスイッチ処理を行うプロセススケジューラ９０ａを有する。従って、各プロセス９１に対応したハードウエアモニタコンテキストが設定され、OS９０のプロセススケジューラ９０ａがモニタコンテキストを切り替える。スケジューラ部としてのプロセススケジューラ９０ａは、上述した実施の形態に係るモニタコンテキストの設定、ハードウエアモニタ機能部の操作等を行うハードウエアモニタ管理部を構成する。

本第１の変形例においても、モニタコンテキストの構成は図３と同じ構成が適用できる。上述した実施の形態との違いは、モニタ動作条件情報３２であり、論理コアIDの代わりにプロセスIDが指定される。また、OS９０のプロセススケジューラ９０ａの処理は、図７に示す論理コアスケジューラの処理において論理コアをプロセスとみなした場合と同じである。図８においても、各論理コアをプロセスとみなせば、動作状態は同等である。

第２の変形例について説明する。図１３は、第２の変形例について説明する。
上述した実施の形態のハードウエアモニタ機能によれば、専用レジスタへのアクセスによってモニタデータの取得が行われていた。しかし、モニタデータを自動的にプロセッサの外部メモリへ所定のタイミングで出力する機能（自動外部出力機能）を備えたハードウエアモニタ機能があれば、データ格納処理のオーバヘッドが無くなること、時系列のモニタデータが取得できること、大容量外部メモリの利用により長時間の性能測定が行えることなど、より優れた性能測定環境が実現できる。そこで、本第２の変形例は、ハードウエアモニタ機能部に、このような自動外部出力機能が備えられた例である。

図１３は、自動外部出力機能を備えたハードウエアモニタ機能部と、上位OSとの関係を説明するための図である。図２との相違点は、ハードウエアモニタ機能部５が、自動的に外部メモリ２００上の所定のバッファ領域２０１にモニタデータを出力することである。ハイパーバイザOS６には、そのバッファ領域２０１の位置を予め設定される。所定のバッファ領域２０１は、複数の物理コアを含む１つのプロセッサ１の外部に設けられた外部メモリ内の記憶領域として、設定される。

モニタコンテキストには、図３のコンテキスト管理情報３０の１つとして、モニタコンテキスト毎に、モニタデータの出力先のバッファ領域２０１のアドレス、サイズ、writeポインタの情報が設定される。

また、図７の論理コアスケジューラの処理では、モニタコンテキストのスイッチ（ステップS8）と同時にバッファ領域の切り替えが行われる。その結果、モニタ動作の開始（ステップ（S17）が行われるときに、新たなバッファ領域にモニタデータが自動的に出力される。そのため、ステップS6,S12におけるモニタ動作の終了では、実施の形態のようなモニタデータの取得及び格納を行う必要はない。なお、タイミングデータについては実施の形態と同様に記録される。

第３の変形例について説明する。第３の変形例として、ハイパーバイザOSあるいはOSが、設定された特定の論理パーティションについてのみハードウエアモニタ機能の利用を許可するようにしてもよい。すなわち、スケジューラ部を有するハイパーバイザOS又はOSが、複数のプロセス等のそれぞれに対して、ハードウエアモニタ機能設定を制限することができるようにしてもよい。
上述した実施の形態によれば、モニタコンテキスト３０のコンテキスト管理情報により、モニタコンテキストの有効と無効の設定が可能であり、全ての論理パーティションについて、モニタコンテキストが有効とされれば、全ての論理パーティションについてのハードウエアモニタ機能設定要が許可される。しかし、セキュリティやコンテンツ保護の観点から、ハードウエアモニタ機能を利用できる論理パーティションを制限したいという要求も考えられる。そのため、ハイパーバイザOSあるいはOSが、設定された特定の論理パーティションについてのみハードウエアモニタ機能の利用を許可し、それ以外の論理パーティションからの要求を全て拒否するような制限機能を有するようにしてもよい。

従って、ハイパーバイザOS等により許可された論理パーティションについては、モニタ動作条件の設定に応じて、上述したような、単一論理パーティションに属する論理コア単位のモニタデータの取得、単一論理パーティション全体に関するモニタデータの取得、あるいはシステム全体に関するモニタデータの取得をすることができ、結果として、上述した実施の形態と同様の機能を実現することができる。

第４の変形例について説明する。第４の変形例として、さらになお、マルチコアプロセッサが複数のハードウエアモニタ機能部を有する場合には、上述したモニタコンテキストの優先度情報に基づいて、複数のハードウエアモニタ機能部の割り当てを行うようにしてもよい。すなわち、複数のハードウエアモニタ機能部を有するプロセッサにおいては、優先度の高いモニタコンテキストから順に、ハードウエアモニタ機能部を割り当てるようにしてもよい。

具体的には、ハードウエアモニタ機能が、１以上のハードウエアモニタ機能部において実行されるとき、ハードウエアモニタ管理部である論理コアスケジューラ６ａ等は、優先度情報の優先度の高い順に、ハードウエアモニタ機能を設定する１以上のモニタコンテキストを割り付ける。

その場合、ハードウエアモニタ機能部の数は、物理コアの数より少なく、各ハードウエアモニタ機能部は同一の仕様であるとすれば、各論理コア上で動作するプロセス間で、ハードウエアモニタ機能に対する競合が発生しても、モニタコンテキストの優先度情報を利用して、優先度の高い順にハードウエアモニタ機能部を割り当てることにより、そのような競合に対処することができる。

なお、以上説明した動作を実行するプログラムは、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ等の可搬媒体や、ハードディスク等の記憶装置等に、その全体あるいは一部が記録され、あるいは記憶されているコンピュータプログラム製品として提供される。そのプログラム中の、上述した動作に対応する各種命令がコンピュータにより読み取られて、動作の全部あるいは一部が実行される。あるいは、そのプログラムの全体あるいは一部を、プログラム製品として通信ネットワークを介して流通または提供することもできる。利用者は、通信ネットワークを介してそのプログラムをダウンロードしてコンピュータにインストールしたり、あるいは記録媒体からコンピュータにインストールすることで、容易に本発明のハードウエアモニタ管理装置を実現することができる。
本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を変えない範囲において、種々の変更、改変等が可能である。

本発明の実施の形態に係わるハードウエアモニタ機能を有するマルチコアプロセッサシステムの構成を示すブロック図である。本発明の実施の形態に係わる、ハードウエアモニタ機能部と上位のOSとの関係を説明するための図である。本発明の実施の形態に係わる、設定されるモニタコンテキストの内容を示す図である。本発明の実施の形態に係わる、最も優先度の高いモニタコンテキストについて、バッファに格納されるモニタデータのフォーマットを示す図である。本発明の実施の形態に係わる、優先度の低いモニタコンテキストについて、バッファに格納されるモニタデータのフォーマットを示す図である。本発明の実施の形態に係わるモニタコンテキストテーブルの構成を示す図である。本発明の実施の形態に係わる論理コアスケジューラの処理の流れの例を示すフローチャートである。本発明の実施の形態に係わる、システム動作時の物理コアの状態、及びハードウエアモニタ機能の動作状態の例を説明するための図である。本発明の実施の形態に係わる、モニタコンテキストテーブルの内容の例を簡単化して示した図である。本発明の実施の形態に係わる、モニタコンテキストAについてバッファの内容の例を示す図である。本発明の実施の形態に係わる、モニタコンテキストBについてのバッファの内容の例を示す図である。本発明の実施の形態の第１の変形例に係るシステムの構成を示すブロック図である。本発明の実施の形態の第２の変形例に係る、自動外部出力機能を備えたハードウエアモニタ機能部と、上位OSとの関係を説明するための図である。

符号の説明

１マルチコアプロセッサ、２主メモリ、３０モニタコンテキスト、５０、５０A モニタコンテキストテーブル、１０１、１０１ａマルチコアプロセッサシステム、１０２下位層、１０３、１０３ａ中位層、１０４上位層

Claims

複数のプロセスを並列に実行する複数の物理プロセッサの動作状態をモニタするハードウエアモニタ機能を設定するために、それぞれがモニタ動作条件と優先度の情報を含む複数のモニタコンテキストが設定されるモニタコンテキストテーブルと、
前記モニタ動作条件を満たす１以上のモニタコンテキストの中で、前記優先度に基づいて決定された前記ハードウエアモニタ機能を設定するモニタコンテキストについては、前記ハードウエアモニタ機能を実行させてモニタデータを取得して、前記モニタ動作条件を満たす時間を示す第１の時間データと共に出力し、前記モニタ動作条件を満たす前記１以上のモニタコンテキストの中で、前記優先度に基づいて決定された前記ハードウエアモニタ機能を設定しないモニタコンテキストについては、前記モニタ動作条件を満たす時間を示す第２の時間データを出力するハードウエアモニタ管理部と、
を有することを特徴とするハードウエアモニタ管理装置。
前記モニタ動作条件は、論理演算式を用いて表現された前記複数のプロセスの実行状態についての条件を含むことを特徴とする請求項１に記載のハードウエアモニタ管理装置。
前記論理演算式は、論理和と論理積の少なくとも１つを用いた式であることを特徴とする請求項２に記載のハードウエアモニタ管理装置。
前記複数のプロセスを並列に実行する複数の論理プロセッサを、前記複数の物理プロセッサに割り付けるスケジューラ部を有し、
該スケジューラ部が、前記モニタコンテキストテーブルと前記ハードウエアモニタ管理部を有することを特徴とする請求項１から３のいずれか１つに記載のハードウエアモニタ管理装置。
複数のプロセスを並列に実行する複数の物理プロセッサの動作状態をモニタするハードウエアモニタ機能を設定するために、それぞれがモニタ動作条件と優先度の情報を含む複数のモニタコンテキストが設定されるモニタコンテキストテーブルを設け、
前記モニタ動作条件を満たす１以上のモニタコンテキストの中で、前記優先度に基づいて決定された前記ハードウエアモニタ機能を設定するモニタコンテキストについては、前記ハードウエアモニタ機能を実行させてモニタデータを取得して、前記モニタ動作条件を満たす時間を示す第１の時間データと共に出力し、
前記モニタ動作条件を満たす前記１以上のモニタコンテキストの中で、前記優先度に基づいて決定された前記ハードウエアモニタ機能を設定しないモニタコンテキストについては、前記モニタ動作条件を満たす時間を示す第２の時間データを出力する、
ことを特徴とするハードウエアモニタ機能の実行方法。