JP7590852B2 - 記憶制御システム、及び、記憶制御方法 - Google Patents

Description

本発明は記憶制御システム及び記憶制御方法に係り、詳しくは、他のアプリケーションプログラムより優先して実行される優先アプリケーションプログラムのキャッシュミスを抑制することによって、優先プリケーションプログラムを高速に実行させる記憶制御システム及び記憶制御方法に関する。

近年、産業用電子制御装置を支える組込みシステム (embedded system)の開発においては、システムの制御性能を向上させること、厳格化する環境規制へ対応すること、そして、システムの自律制御に伴い、新たな制御演算処理を追加しなければならないこと等を理由として、組込みシステムのソフトウェア、プログラム、そして、アプリケーションプログラムに対する負荷が大きくなってきている。

例えば、自律制御では、多くの場合、組込みシステムが活動する状況に基づいてルールが設定されており、制御対象としてのオブジェクト（例えば、車両等）は、このルールに従って動作することを前提にして装置の通常の動作がプログラムされている。このルールから逸脱する状況が発生した際、これに対処するため、オブジェクトの緊急制御が必要になる。

しかしながら、緊急制御に関与しないアプリケーションプログラムがキャッシュメモリを消費し、その結果、緊急制御に欠くことができない優先アプリケーションプログラムのキャッシュヒットミスを誘発して優先アプリケーションプログラムの高速化が図れず、ひいては、緊急制御に対応できないというおそれがある。

特開2007-200277号(特許文献１)は、ＣＰＵがアイドル処理を実行している時間帯に高優先度処理をダミー実行してインストラクションキャッシュメモリ内に高優先度処理のプログラムを配置し、その後、正規のタイミングで高優先度処理を実行する際には、インストラクションキャッシュメモリに既に高優先度処理のプログラムが配置されているためヒット率が高くなり、その結果、高優先度処理の実行時間を短縮できるマイクロコンピュータを開示している。

特開2007-200277号

システムの高速化を実現するためには、優先アプリケーションプログラムだけではなく、データもキャッシュメモリに維持される必要があるが、既述の特許文献１では後者については配慮されていない。そして、例えば、自動車の自動運転に於ける衝突回避の類の優先アプリケーションプログラムを正規のタイミングより前にダミー実行しても、周囲に緊急回避すべき障害物が存在しないなど、実際に緊急制御の際の状況と異なり、そして、入力情報も実際のものとは異なるため、結果として、緊急制御に必要な命令やデータをキャッシュメモリに維持できない。そもそも、ダミー実行によって、優先アプリケーションプログラムの全ての分岐やアドレスを網羅できるわけでもない。

本発明は、優先アプリケーションプログラムの動作中のキャッシュヒットミスを、優先アプリケーションプログラムの動作タイミングの如何に拘らず抑制するようにして、優先アプリケーションプログラムの高速化を達成しようとする記憶制御技術の提供を目的とする。

前記目的を達成するために、本発明は、データの記憶制御システムであって、 複数のコントローラを備え、前記複数のコントローラのうち第１のコントローラは、所定条件下で他のアプリケーションプログラムより優先される少なくとも一つの優先アプリケーションプログラムを実行し、前記複数のコントローラのうち前記第１のコントローラ以外の他のコントローラである第２のコントローラは、前記優先アプリケーションプログラムの実行以前に当該優先アプリケーションプログラムの実行のための必要データを、当該優先アプリケーションプログラムがアクセス可能なキャッシュメモリに維持させておくようにする、というものである。

本発明によれば、優先アプリケーションプログラムの動作中のキャッシュヒットミスを、優先アプリケーションプログラムの動作タイミングの如何に拘らず抑制するようにして、優先アプリケーションプログラムの高速化を達成することができる。

本発明の第１の実施形態に係る制御システムのハードウェアブロック図である。 ＬＲＵカウンタを用いたキャッシュの管理方式を説明するためのテーブルである。 図１の制御システムの機能ブロックである。 コア配置管理情報としての管理テーブルの一例を示す。 維持対象データの管理情報としての管理テーブルの一例である。 キャッシュ維持アプリケーションプログラムの動作例を説明するフローチャートである。 キャッシュメモリへのデータの維持の第１の態様を示すブロック図である。 キャッシュメモリへのデータの維持の第２の態様を示すブロック図である。 複数のアプリケーションプログラムのタイミングチャートである。 第２の実施形態に係る制御システムの機能ブロック図である。 第２の実施形態に係る、維持対象管理テーブルである。 第３の実施形態に係る、維持対象管理テーブルである。 第３の実施形態に係る、キャッシュ維持アプリケーションプログラムの動作を説明するフローチャートである。 第３の実施形態において、対象データをキャッシュメモリに維持されるアプリケーションプログラムの遷移を表したタイムチャートである。 第４の実施形態に係る制御システムの機能ブロック図である。 第４の実施形態に係る維持対象管理情報一例を示す。 第４の実施形態に於ける、キャシュ維持アプリケーションプログラムの動作を示すフローチャートである。 Ｌ１キャッシュもＬ２キャッシュ同様に、コア外でＣＰＵ内に構成されている例を示す、制御システムのハードウェアブロック図である。 Ｌ１キャッシュとＬ２キャッシュとも、マルチコアの夫々のコア内に構成されている例を示す、制御システムのハードウェアブロック図である。 図１のＬ１キャッシュとＬ２キャッシュとに加えて、各コア外でＣＰＵ内にＬ３キャッシュが追加されている例を示す、制御システムのハードウェアブロック図である。 図１９の制御システムの各コア外でＣＰＵ内にＬ３キャッシュが追加されている例を示す、制御システムのハードウェアロック図である。

本発明は、ソフトウェアの実行に必要な情報である、データ、パラメータ、そして、コマンド等の記憶制御のための制御システム、そして、その制御方法であり、例えば、自動車、鉄道、航空機、ロボット、通信装置、ネットワーク装置、ビル設備等の制御対象の駆動のために必要な情報の記憶を制御する制御システムである。制御システムは制御対象とともに全体システムを構成する。制御システムは、マイコン、パソコン、または、サーバである。なお、ソフトウェアの実行に必要な情報である、データ、パラメータ、コマンド等を“データ”として括って、特許請求の範囲、そして、実施形態において表記した。

前記制御システムの実施形態を、図面を用いて説明する。図１に、マルチコアプロセッサを備える制御システム（制御装置）１０１のハードウェアブロック図を示す。制御システム１０１はＣＰＵ１０２、メインメモリ１０３、及び、周辺装置１０４を含む。ＣＰＵ１０２は、夫々、アプリケーションプログラム(タスク)を実行する、Ｎ個のコア１０５～１０７を搭載し、夫々のコアにＬ１キャッシュ１０８～１１０が設けられている。コアは請求項に記載のコントローラの一例である。メインメモリとキャッシュメモリは夫々記憶資源である。なお、以後、実施形態、そして、特許請求の範囲において、アプリケーションプログラムをアプリケーションと略称する。メインメモリのデータは、ＨＤＤ、フラッシュメモリドライブ等の非可搬型記憶媒体から読み出されて設定される。

夫々のコアとは別に、ＣＰＵ１０２内にＬ２キャッシュ１１１が存在する。Ｌ１キャッシュ１０８～１１０とＬ２キャッシュ１１１とによってキャッシュメモリが構成される。Ｌ１キャッシュ１０８～１１０とＬ２キャッシュ１１１とは夫々メインメモリ１０３に保管されている命令およびデータを一時的に保持する。Ｌ１キャッシュ１０８～１１０はＬ２キャッシュ１１１よりも短時間で書き込みや読み出しを完了できる。Ｌ２キャッシュ１１１は、Ｌ１キャッシュ１０８～１１０とメインメモリ１０３の中間に位置して両者を繋ぐ機能を有する。なお、Ｌ１キャッシュ１０８～１１０、及び、Ｌ２キャッシュ１１１の配置は図１の例に限らず、Ｌ１キャッシュ１０８～１１０をまとめて全コア共通で管理される形態や、Ｌ２キャッシュ１１１を各コアで管理する等の他の形態でもよい。他の形態については後述する。

制御システム１０１は周辺装置１０４を介して外部と通信する。制御システム１０１は、例えば、自動車のコントロールユニットとして、周辺装置１０４を介して、カメラによる画像データ、超音波センサやレダーセンサ、速度センサ、加速度センサ等による検出データ、を得て、制御対象としての自動車に対して緊急制御（衝突回避等）を実行するよう、制御対象の操作系（ブレーキ装置、操舵装置、懸架装置等）に制御信号を送信する。なお、メインメモリやキャッシュメモリに格納されるコマンドも０／１の並びとして扱うことができるため、既述のとおり、狭義の“データ”に加えて、プログラム、コマンドも広義の“データ”に含めることとした。

Ｌ１キャッシュ１０８～１１０やＬ２キャッシュ１１１はメインメモリ１０３に格納されたデータの少なくとも一部を格納する。コアは、Ｌ１キャッシュ内に必要なデータが存在しない場合、Ｌ２キャッシュからデータを読み出し、Ｌ２キャッシュにもデータがない場合にはメインメモリ１０３からデータを読み出す。コアは読み出したデータによってＬ１キャッシュ内のデータを入れ替える。この入れ替えに多く用いられる方式がＬＲＵ(Least Recent Used)である。これは、キャッシュメモリに保存されたデータごとにＬＲＵカウンタを設けて、データに最後にアクセスした順番を管理することによって、高頻度でアクセスするデータを優先的にキャッシュメモリに残すという管理方式である。

ＬＲＵカウンタを用いたキャッシュメモリの管理方式の概要を図２に示す。図２は、管理方式の一例として、キャッシュメモリの実装方式の一つであるフルセットアソシアティブ方式を示している。この方式は、キャッシュメモリ内のデータを、アドレス情報の代わりにＴＡＧによって管理する。アプリケーションは、ＴＡＧにヒットした箇所のデータを参照する。例えば、アプリケーションはデータを読み出す際、アプリケーションを実行するコア１(１０５)のＬ１キャッシュ１０８にアクセスし、このデータが存在する場合にはこれを用いる。アプリケーションはアクセスしたデータのＬＲＵカウンタを０に設定し、その他データのＬＲＵカウンタを１インクリメントする。なお、アクセスしたデータよりＬＲＵカウンタの値が大きいものはインクリメントされない。

Ｌ１キャッシュ１０８に対象データが存在しない場合、アプリケーションは、Ｌ２キャッシュ１１１にアクセスし、データが存在する場合にはこれを利用する。アプリケーションは、Ｌ１キャッシュ１０８に保存されているデータのうちＬＲＵカウンタが一番大きいデータを削除し、Ｌ２キャッシュ１１１から読み込んだデータをＬ１キャッシュ１０８に保存のうえ、当該データのＬＲＵカウンタを０に設定、その他データのＬＲＵカウンタを１インクリメントする。

コアは、キャッシュメモリに格納されたデータ数がキャッシュメモリのライン数を超えた場合に、キャッシュメモリからデータを削除する。Ｌ１キャッシュ１０８から削除されたデータはＬ２キャッシュ１１１へ保存される。

アプリケーションは、Ｌ２キャッシュ１１１にも必要なデータが存在しない場合、メインメモリ１０３にアクセスし、目的のデータを取得する。この際、アプリケーションは、Ｌ１キャッシュ１０８に保存されているデータのうちＬＲＵカウンタの値が一番大きいデータを削除し、メインメモリ１０３から読み込んだデータを保存のうえ、当該データのＬＲＵカウンタを０に設定、その他データのＬＲＵカウンタを１インクリメントする。

さらに、コアは、Ｌ２キャッシュ１１１に保存されているデータのうちＬＲＵカウンタの値が一番大きいデータを削除し、メインメモリ１０３から読み込んだデータをＬ２キャッシュ１１１に保存し、当該データのＬＲＵカウンタの値を０に設定し、その他データのＬＲＵカウンタの値を１インクリメントする。

アプリケーションは、Ｌ２キャッシュ１１１から削除したデータをメインメモリ１０３に保存する。アプリケーションは、Ｌ２キャッシュ１１１に保存されているデータのうちＬＲＵカウンタが一番大きいデータを削除し、メインメモリ１０３から読み込んだデータを保存のうえ、当該データのＬＲＵカウンタを０に設定し、その他データのＬＲＵカウンタの値を１インクリメントする。

アクセスの内容が書き込みであった場合、アプリケーションは、Ｌ１キャッシュ１０８へライトデータを格納する。その際、アプリケーションは、当該データがＬ１キャッシュ１０８に存在すると、当該データのＬＲＵカウンタを“０”に設定し、その他データのＬＲＵカウンタを1インクリメントする。アクセスしたデータよりＬＲＵカウンタの値が大きいもののインクリメントは実行されない。

前記ライトデータがＬ１キャッシュ１０８に存在しない場合、アプリケーションは、ＬＲＵカウンタが一番大きいデータを削除し、そして、ライトデータを格納して、そのＬＲＵカウンタを“０”に設定し、その他データのＬＲＵカウンタを1インクリメントする。キャッシュメモリから削除されたデータの扱いは、既述した、データの読み出しにおける取り扱いと同じである。

なお、ライトデータは、既述のとおり、ライトバックと呼ばれる方式によって管理されるが、データの書き込み時に毎回Ｌ１キャッシュ１０８だけでなくＬ２キャッシュ１１１およびメインメモリ１０３にデータが書込まれるライトスルー方式の適用が否定されるものではない。

キャッシュメモリの内部を区切ってブロックごとにＬＲＵが管理されるセットアソシアティブ方式、そして、キャッシュメモリの内部が区切られないフルセットアソシアティブ方式が存在する。両者とも、ＬＲＵカウンタの基本的動作は同様である。図１の制御システムは、フルセットアソシアティブ方式、セットアソシアティブ方式およびダイレクトマップ方式のいずれをも採用することができる。

キャッシュメモリへのデータの置き換えを管理する方式にはＬＲＵの他に、ラウンドロビン、ランダム等があるが、いずれかに制限されるものではないではない。キャッシュメモリのラインサイズは通常３２～６４バイトであり、サイズは限定されるものではない。

Ｌ１キャッシュ１０８～１１０、及び、Ｌ２キャッシュ１１１に、アプリケーションが必要とするデータが存在せず、アプリケーションによって、メインメモリ１０３へアクセスされなければならないデータが多い場合、アプリケーションの実行に大幅な遅延が生じる。そこで、緊急時等高速に処理されなければならないアプリケーション（優先アプリケーション）が必要とするデータは極力Ｌ１キャッシュ１０８～１１０、及び／又は、Ｌ２キャッシュ１１１に維持されることが好ましい。これを、制御システムの機能ブロック図である図３に基づいて説明する。

図３は、ＣＰＵ１０２内部のソフトウェアの構成、そして、メインメモリ１０３内のデータ構造の一部を示す。ＣＰＵ１０２は、コア１（１０５）に、必要時、例えば、緊急時に優先して実行されるべき優先アプリケーション３０１と、それ以外のアプリケーション（通常アプリケーション）３０２とが混在して駆動させている。優先アプリケーションとは、例えば、相対的に優先度が高いアプリケーションをいい、通常アプリケーションとは相対的に優先度が中小程度のアプリケーションをいう。優先アプリケーション３０１を高優先アプリケーションと呼び、通常アプリケーション３０２を低優先アプリケーションと呼んでもよい。

さらに、ＣＰＵ１０２は、スケジューリングモジュール３０３をコア１（１０５）以外のコアの一つ又は複数において動作させている。図３は、スケジューリングモジュール３０３がコア２（１０６）において実行されることを示している。スケジューリングモジュール３０３は、複数のアプリケーション夫々について、その駆動を開始するタイミング、そして、駆動を中断するタイミング等を制御している。すなわち、スケジューリングモジュール３０３は、コア１の優先アプリケーション３０１、通常アプリケーション３０２、そして、後述のキャッシュ維持アプリケーション３０４夫々の動作のタイミングを制御する。

スケジューリングモジュール３０３は、所定条件で、例えば、緊急時に、コア１が、通常アプリケーション３０２の駆動中でもこれを中断する等して、優先アプリケーション３０１を優先して実行させるようにする。スケジューリングモジュール３０３は、コア毎のアプリケーションの実装の形態を、後述のコア配置管理情報３０９に基づいて知ることができる。なお、“モジュール”とはソフトウェアによって実行される機能を意味する。“モジュール”を、“手段”、“機能”、“要素”、“回路”、又は、“部”等他の用語に置き換えてもよい。モジュールは、ハードウェア、又は、ソフトウェアとハードウェアとの協働によって、実現されてもよい。どのコアにどのようなアプリケーションを配置するかは、コアの負荷に応じて適宜、設定、又は、変更されてよい。

スケジューリングモジュール３０３は、コア配置管理情報３０９に基づいて、優先アプリケーション３０１、通常アプリケーション３０２が稼働している、コア１とは別なコア（コア２）に、キャッシュ維持アプリケーション３０４を稼働させている。図４に、コア配置管理情報３０９としての管理テーブルを示す。コア配置管理情報３０９は、アプリケーションの種別と、当該アプリケーションを実行するコアとの関係を規定している。コア配置管理情報３０９は、制御システム１０１のメインメモリ１０３に格納されている。コア配置管理情報３０９は制御システム１０１の管理者によってメインメモリ１０３に登録されてよい。

キャッシュ維持アプリケーション３０４は、優先アプリケーション３０１がキャッシュヒットミスを緊急時に発生して動作遅延をきたさないように、優先アプリケーション３０１に必要なデータ（維持対象データ）を、維持対象管理情報３０８に基づいて、キャッシュメモリに、事前に、維持、格納、登録、記憶、保持、保有、又は、設定しておく。キャッシュ維持アプリケーション３０４のこの動作を、“キャッシュ維持”と記載する。維持対象管理情報３０８はメインメモリ１０３に記録されている。

図３に示すように、キャッシュ維持アプリケーション３０４は、データアクセスモジュール３０６と維持対象管理モジュール３０７とを備える。維持対象管理機モジュール３０７はメインメモリ１０３の維持対象管理情報３０８を参照して、参照情報をデータアクセスモジュール３０６に渡し、データアクセスモジュール３０６はキャッシュメモリにアクセスして、キャッシュメモリに維持対象データを格納する。データが格納されるキャッシュメモリは、Ｌ１キャッシュ１０８、Ｌ２キャッシュ１１１、そして、Ｌ１キャッシュ１０８の少なくとも一つでよい。要するに、優先アプリケーション３０１がアクセスできるキャッシュメモリであればよい。

キャッシュ維持アプリケーション３０４は、例えば、タイマ割込み処理によって、継続的に実施されればよい。キャッシュ維持アプリケーション３０４が優先アプリケーション３０１の動作中に実行されることを妨げるものではないが、同じデータへの同時アクセスによる競合が発生して、優先アプリケーションの動作遅延を引き起こすのを防ぐため、優先アプリケーション３０１の駆動中にはスケジューリングモジュール３０３がキャッシュ維持アプリケーション３０４を中断すればよい。

コア２において、スケジューリングモジュール３０３はキャッシュ維持アプリケーション３０４を優先して動作させる。スケジューリングモジュール３０３は、キャッシュ維持アプリケーション３０４を動作させていない間、他アプリケーション３０５を駆動することができる。スケジューリングモジュール３０３は、キャッシュ維持アプリケーション３０４を常に高優先度で運用してもよい。また、スケジューリングモジュール３０３は他アプリケーション３０５が動作していない隙間時間に、キャッシュ維持アプリケーション３０４を動作させてもよいし、さらにまた、スケジューリングモジュール３０３はキャッシュ維持アプリケーション３０４を周期的に動作させてもよい。

図５に、維持対象データの管理情報（維持対象管理情報３０８）としての管理テーブルの一例を示す。管理テーブルには、対象番号（エントリ）と、データが格納されているメインメモリアドレスと、データの変数型とが記録されている。これらの管理情報によって、データアクセスモジュール３０６は維持対象データを特定することができる。

優先アプリケーション３０１が必要とするデータは予め判明しているため、維持対象管理モジュール３０７は、維持対象データを維持対象管理情報３０８としてメインメモリ１０３に予め設定（登録）し、また、これを更新することができる。データアクセスモジュール３０６は、維持対象管理情報３０８に基づいて、メインメモリ１０３にアクセスしてデータを取り込み、当該データをキャッシュメモリに記録する。

キャッシュ維持アプリケーション３０４を詳しく説明する。図６は、キャッシュ維持アプリケーション３０４の動作例を説明するフローチャートである。キャッシュ維持アプリケーション３０４は、維持対象管理モジュール３０７を実行して維持対象を決定するとデータアクセスモジュール３０６にキャッシュ維持を実行させる。

維持対象管理モジュール３０７は、維持対象を選択するための選択番号を変数として保持し、フローチャートの起動後にこれを０にセットする(Ｓ４０１)。その後、維持対象管理モジュール３０７は、選択番号と維持対象管理テーブル（維持対象管理情報３０８）の対象番号が一致する箇所を参照し、対象のアドレスおよびデータ型情報を取得する(Ｓ４０２)。

取得した情報をもとに、データアクセスモジュール３０６は対象のデータ型およびアドレスを指定してデータアクセスを行う(Ｓ４０３)。データアクセスモジュール３０６は、データアクセスによって、メインメモリ１０３からＬ１キャッシュ、又は、Ｌ２キャッシュへデータを格納し、そして、これらキャッシュメモリのＬＲＵカウンタを更新して、優先アプリケーション３０１が必要とするデータが優先アプリケーション３０１の実行時にキャッシュメモリから削除された状態になっていないように、キャッシュメモリに対象データが維持されるようにする。次いで、維持対象管理モジュール３０７は、選択番号を１インクリメントする(Ｓ４０４)。

選択番号の値がキャッシュ維持の対象の数と同数まで達すると、即ち、データアクセスモジュール３０６が全ての維持対象にアクセスし終わると(Ｓ４０５：Ｙｅｓ)、データアクセスモジュール３０６は、選択番号を０にセットする。選択番号の値がキャッシュ維持対象の数まで達していない場合（Ｓ４０５：Ｎｏ)、ステップＳ４０７が終了シーケンスに入っているか確認し、これを肯定するとフローチャートが終了する（Ｓ４０７：Ｙｅｓ）。ステップＳ４０７がＮｏを判定すると、ステップＳ４０２にリターンする(Ｓ４０７：Ｎｏ)。図４のフローチャートによって、管理テーブル３０８に登録された全ての維持対象データがキャッシュメモリに設定され、突然に、優先アプリケーション３０１が動作してもキャッシュヒットミスが生じないようにできる。

なお、フローチャート終了の管理はフラグを用いた管理方法や、killシグナルやpthread_cancelのようなシグナルを、維持対象管理モジュール３０７が受け取ってキャンセルハンドラを呼びだす仕組み等、格別限定されない。また、維持対象管理情報３０８に、データ型の代わりにデータサイズが登録され、データアクセスモジュール３０６は、memcopyのような変数型によらずサイズを指定して、データのリード、ライトを実行してもよい。

既述のデータアクセス（図６：Ｓ４０３）について詳しく説明する。データアクセスモジュール３０６のデータアクセスは読み出しと書き込みとを含む。データ読み出しは、if文による参照やzeroレジスタへのコピー等により実現される。プログラミング言語にもよるが、アセンブリを直接指定可能な場合にはload命令等がある。

そのほか、例えば、ＡＲＭのＣＰＵに実装されているプリフェッチ命令でも読み出しと同様の効果が得られる。キャッシュメモリのラインサイズは通常３２～６４バイトが多く、キャッシュメモリのラインに格納されている全データをアクセスする必要は無く、ラインごとに１つのデータをアクセスすることにより同ラインに格納されたデータのキャッシュ維持が可能である。

データ書き込みは、例えば target_data = target_data + 0;の形で対象自身に同じデータを書き込むなどにより実現される。アセンブリが直接指定可能な場合、store命令によってもよい。

データアクセス（Ｓ４０３）に基づく、キャッシュメモリへのデータの維持は、Ｌ１キャッシュ１０９、及び、／又は、Ｌ２キャッシュ１１１への維持対象データの登録を含む。例えば、図７において、データアクセスモジュール３０６は、Ｌ１キャッシュ１０９に維持対象データが存在すればＬＲＵカウンタを更新し、当該データがＬ１キャッシュ１０９に存在せず、Ｌ２キャッシュ１１１に存在する場合には、Ｌ２キャッシュからデータを読み出してＬＲＵカウンタを更新して格納する。データがＬ２キャッシュ１１１にも存在しない場合には、データアクセスモジュール３０６は、メインメモリ１０３からデータを読み出して、データをＬ２キャッシュ１１１にＬＲＵカウンタを更新して格納する（Ｓ１）。

以上により、少なくともＬ２キャッシュ１１１に、優先アプリケーション３０１が必要とするデータが維持された状態を、優先アプリケーション３０１が動作する前に形成しておくことが可能になる。なお、Ｌ２キャッシュ１１１はＬ１キャッシュ１０９に比べて、アクセスのための時間を要するが、キャッシュ維持アプリケーション３０４の負荷は小さい、と云ってよい。

また、図８に示すように、データアクセスモジュール３０６は、メインメモリ１０３から維持対象データを読み出し、当該データをＬ１キャッシュ１０９の同じアドレスへ書込むことによって、Ｌ１キャッシュ１０９へ維持対象データを格納することができる（Ｓ２）。

一方、コア１に存在する所定アプリケーションがスヌープ機能に基づいてコア２にあるＬ１キャッシュ１０９から維持対象データを読み込んで、当該データをＬ１キャッシュ１０８に維持することが可能となる（Ｓ３）。スヌープの機能の分、キャッシュ維持アプリケーション３０４に加わる負荷は大きくなるが、優先アプリケーション３０１は自身のコア１（１０５）のＬ１キャッシュ１０８の維持対象データにアクセスできるために、優先アプリケーション３０１が実行される際のリアルタイム性が向上する。キャッシュの実装方法やアプリケーション構成によってはＬ２キャッシュ１１１に前記対象データを維持するのが困難な場合もあるため、Ｌ１キャッシュ１０９に維持対象データを格納することは望ましい。

図９に、コア２がキャッシュ維持アプリケーション３０４を実行している態様（図３）とキャシュアプリケーション３０４が付加されていない従来態様とについて、タイミングチャートに於ける比較結果を示す。図９の上段が後者のチャートを示し、図９の後段が前者のチャートである。図９の縦軸がアプリケーションの優先度を示し、横軸が時間経過を示す。縦軸の矢印方向が、優先度が高いことを示す。３０１は既述のとおり優先アプリケーションであり、３０２は通常アプリケーションであり、夫々コア１に属する。３０４は既述のとおり、キャシュ維持アプリケーションである。

図９の“Ｈ”は、前者に於ける優先アプリケーション３０１の所要時間と後者に於ける優先アプリケーション３０１の所要時間との差分である。後者においては、コア２にキャッシュ維持アプリケーション３０４が存在しないため、これが、オーバーヘッドとなって、優先アプリケーション３０１の開始から終了までＨで示される時間幅の分長くなる。

従来、通常アプリケーション３０２が膨大なデータを利用してキャッシュを使いきってしまうと、優先アプリケーション３０１に係るデータはキャッシュメモリから削除されてしまい、優先アプリケーション３０１の遅延に繋がり、そのリアルタイム性が保証されない。キャッシュ維持アプリケーション３０４を、優先アプリケーション３０１とこれ以外のアプリケーション３０２とが混在するコアと別コアにおいて駆動させることにより、優先アプリケーション３０１の優先処理を妨げることなく、優先アプリケーション３０１が使用する可能性がある全てのデータ(命令およびデータ)をキャッシュメモリに維持できる。

既述の従来例のように、優先アプリケーションのキャッシュヒットミスを防ぐために、優先アプリケーションを非緊急時に実行しても、緊急制御時に於ける、優先アプリケーションのための入力値とは異なるため、結局のところ、緊急制御が必要になった時点では、優先アプリケーションに必要な命令やデータをキャッシュ維持できない。

一方、既述の実施形態によれば、キャシュ維持アプリケーション３０４によって、緊急時直前までに、優先アプリケーションに必要な命令やデータをキャッシュメモリに維持することができる。なお、図１に係る制御システムは、自動車の自動運転の他、電源ユニット制御やロボット制御等、様々な緊急制御を必要とする技術分野に適用することができる。

マルチコアの制御システムに於ける、アプリケーションの高速化方法としてはシングルコア向けアプリケーションを移植する方法があるが、シングルコア向けに作られたプログラム群をマルチコア上で実行する場合、実行タイミングの変化などによりタスク間のデッドロックやバグの誘発という危険性があり、プログラムの設計やその検証のやり直しが必要となる。これに対して、既述の実施形態によれば、この種の対応を必要とすることなく、優先アプリケーションの高速化を達成することができる。

次に、第２の実施形態について説明する。図１０は、第２の実施形態に係る制御システムの機能ブロック図であり、図１１は、第２の実施形態に係る維持対象管理情報３０８である。第２の実施形態が第１の実施形態と異なる点は、キャシュ維持アプリケーション３０４が維持依頼管理モジュール９０１を備えることである。維持依頼管理モジュール９０１は、優先アプリケーション３０１からのリクエストによって、維持対象管理モジュール３０７を経由して、維持対象管理情報３０８に、維持対象データの帰属先としてのアプリケーションを追加、変更、又は、削除する。

図１１の維持対象管理情報３０８には、このアプリケーション名が登録されている。リクエストの内容は、アプリケーションのＩＤ、維持対象データ数、維持対象データそれぞれのアドレス、および、変数型を含む。アプリケーションのＩＤはスレッドＩＤやプロセスＩＤなど、アプリケーションをコア１に実装する形態に合わせて変えてよい。維持対象データの変数型はデータのサイズに置き換えてもよい。

状況変化により、維持対象データをキャッシュメモリに維持することが必要無くなった際、優先アプリケーション３０１は、キャッシュ維持をキャンセルできるようにしてもよい。維持依頼管理モジュール９０１は、優先アプリケーション３０１からキャンセルリクエストを受け取り、維持対象管理モジュール３０７を経由して、維持対象管情報３０８から、キャンセルリクエストに係るアプリケーションの情報を削除する。キャンセルリクエストの内容はアプリケーションのＩＤ、キャンセル対象データ数、キャンセル対象データそれぞれのアドレス及び変数型を含む。

キャンセル時のデータ指定を簡単化するため、維持依頼管理モジュール９０１は、依頼時に、維持対象データ群と結びついたラベルを生成し、依頼元アプリケーションへラベルを返し、キャンセル時にラベルを指定する形式を採ってもよい。さらに、通常アプリケーション３０２が誤って依頼をキャンセルしてしまうことを防ぐため、維持依頼管理モジュール９０１は、優先アプリケーション３０１以外からのキャンセル通知を拒否する形式や、キャンセル通知を受諾可能なアプリケーションを指定する形式を採用してもよい。

第２の実施形態によれば、システムの状況変化に応じて、複数の優先アプリケーションの中から、高速化を図るべき優先アプリケーションを変更することができる。例えば、自動車の自動運転システムにおいて、ドライバによる手動運転をサポートするモードと、システムが運転する自動運転のモードでは、夫々必要もしくは重要となるアプリケーションが異なる可能性がある。自動車に限らず、状況変化やモードの遷移などによりリアルタイム性を保障すべきアプリケーションが変わるようなシステムにおいて、アプリケーションからの依頼によりキャッシュ維持対象を変更することで、状況に応じて適したアプリケーションの高速化が可能となる。

次に、制御システムの第３の実施形態について説明する。第３の実施形態は、複数の優先アプリケーション３０１の優先度に基づいて、キャッシュメモリに、複数の優先アプリケーション夫々の維持対象データの格納の順番、及び、頻度を決定することに特徴を有する。優先アプリケーションが複数存在するなど、キャッシュメモリに維持すべき対象データ数が多い場合、全データをキャッシュメモリに格納できない可能性がある。そこで、維持対象管理モジュール３０７（図３、図 １０）は、例えば、複数の優先アプリケーション夫々の優先度にしたがって、キャッシュメモリに対象データを維持すべき、優先アプリケーションを決定、判定、又は、選定することとした。これを図１２～１４を用いて説明する。

図１２は、第３の実施形態に係る維持対象管理情報３０８の一例である。この管理テーブル３０８には、優先アプリケーションの優先度が追加されている。図１３は、キャッシュ維持アプリケーション３０４の動作を説明するフローチャートである。図１４は、キャッシュ維持アプリケーション３０４によって、対象データをキャッシュメモリに維持されるアプリケーションの遷移を表したタイムチャートである。

維持対象管理情報３０８は、図１２に示されるように、アプリケーションの優先度、インデックス、対象数、連続維持数が追加されており、各データとアプリケーションとをタグ（インデックス）によって結び付けている。維持対象管理情報３０８は、維持数と、対象アプリケーションごとの選択番号とを保持している。

図１３に示すように、まず、維持対象管理モジュール３０７は、維持数と各選択番号を０にセットする(Ｓ１２０１)。その後、維持対象管理モジュール３０７は、維持対象管理情報３０８（図１２）にて管理している対象アプリケーション間の優先度を比較し、優先度比率に応じて各アプリケーションの連続維持数を決定する(Ｓ１２０２)。

図１２のように、アプリケーション間の優先度比率（App_A:App_B）が２：１であった場合、維持対象管理モジュール３０７は、アプリケーションＡとアプリケーションＢについて、連続してキャッシュ維持を行う対象数の比率を優先度の比率と同様に２：１にする。そのうえで、データアクセスモジュール３０６は、優先度の高いアプリケーションから順番に選択する(Ｓ１２０３)。

データアクセスモジュール３０６は、選択したアプリケーションのインデックスを参照し、選択したアプリケーションの中で選択番号と一致するデータを選択し(Ｓ１２０４)、対象データのアドレス及び変数型情報を取得する(Ｓ１２０５)。データアクセスモジュール３０６は、取得したデータ情報をもとに、データアクセスを行う(Ｓ１２０６)。

データアクセスモジュール３０６は、維持数および選択番号を１インクリメントし(Ｓ１２０７)、選択番号が選択アプリケーションの対象数に達した場合(Ｓ１２０８：Ｙｅｓ)、選択番号を０にリセットする(Ｓ１２０９)。選択番号が選択アプリケーションの対象数に到達していない場合、そのまま次のステップへ進む(Ｓ１２０８：Ｎｏ)。

データアクセスモジュール３０６は、維持数が選択アプリケーションの連続維持数に達した場合(Ｓ１２１０：Ｙｅｓ)、選択アプリケーションを次の優先度のアプリケーションに変更する(Ｓ１２１１)。維持数が選択アプリケーションの連続維持数に到達していない場合、キャシュ維持アプリケーション３０４はそのまま次のステップへ進む(Ｓ１２１０のＮｏ)。

その後、データアクセスモジュール３０６は、システムが終了シーケンスに入っているか確認し、入っている場合にはシステムを終了する（Ｓ１２１２：Ｙｅｓ）。システム終了でない場合、キャシュ維持アプリケーション３０４はＳ１２０４へ戻り、システム終了までＳ１２０４～Ｓ１２１２を繰り返す(Ｓ１２１２：Ｎｏ)。

データアクセスモジュール３０６は、図１４に示すように、App_A（アプリケーションＡ）用の維持対象データの全てにアクセスしたのち、App_B（アプリケーションＢ）用の維持対象データの途中までアクセスする。次いで、キャシュ維持アプリケーション３０４は、App_Aのための維持に戻り、これを完了したらApp_B用の残りのための維持を継続する。以後これを繰り返す。アプリケーションＡとアプリケーションＢとの間の比率は、アプリケーションの優先度に依らず、イベント発生からデッドラインまでの時間や頻度等によって決定されてもよい。さらに、連続維持数を連続維持時間に代えてもよい。

第３の実施例によれば、アプリケーションの優劣に基づいて、アプリケーションのキャッシュに維持対象データの格納順番や頻度を制御することにより、優先アプリケーションが複数あっても、その中でより重要度が高いアプリケーションを優先して維持対象データをキャッシュメモリに保持させることが可能となる。なお、同一アプリケーション用の複数の維持対象データ間で優先度等の優劣を設けてキャッシュへメモリへのデータ維持を実行してもよい。

次に、第４の実施形態について説明する。この実施形態は、キャシュメモリにデータを維持すべき対象となるアプリケーションが複数存在する場合に、アプリケーションが起動するまでの時間に基づいて、複数のアプリケーション間でのデータの維持に関する順番等の優劣を決定する点に特徴を有する。図１５は、第４の実施形態に係る制御システムの機能ブロック図である。図１６は、第４の実施形態に係る維持対象管理情報３０８の一例を示す。図１７は、第４の実施形態に於ける、キャシュ維持アプリケーション３０４の動作を示すフローチャートである。

キャッシュ維持アプリケーション３０４は、既述の第２の実施形態に係る制御システムの機能ブロックに加えて、周期/時間管理モジュール１４０１とタイマ設定モジュール１４０２とを備える。周期/時間管理モジュール１４０１は、図１６の維持対象管理情報３０８に示すように、各アプリケーションについて、アプリケーションの実行周期と、当該周期と時刻に基づいて各アプリケーションが起動されるまでの時間と、を管理している。

周期/時間管理モジュール１４０１は、先ず、各アプリケーションの周期と前回の起動時刻から次の起動時刻を更新し、起動時刻が近いアプリケーションを選択する(Ｓ１６０１)。その後は、データアクセスモジュール３０６は、実施例３と同様に選択したアプリケーションの維持対象データ情報を取得し(Ｓ１６０２)、データアクセスを行う(Ｓ１６０３)。これをシステムが終了するまで繰り返す(Ｓ１６０４)。

周期/時間管理モジュール１４０１は、複数のアプリケーションの中から特定のアプリケーションを選択する際、キャッシュ維持に要する時間に基づいて、選択したアプリケーションが起動するまでにキャッシュ維持が完了できるアプリケーションを選択するようにしてもよい。また、キャッシュ維持アプリケーション３０４を常に動作させるのではなく、対象アプリケーションの次回起動時刻から維持に必要な起動時刻を算出し、タイマ設定機能１４０２によりタイマ１４０３をセットすることで、キャッシュ維持アプリケーションの駆動時刻を制御してもよい。

第４の実施形態によれば、キャッシュ維持対象としての複数のアプリケーションの夫々の次回起動時刻、即ち、夫々のアプリケーションの駆動タイミングに基づいて、複数のアプリケーションに対する、キャッシュ維持の優劣の一つとしての順番を決定することにより、実行タイミングが近いアプリケーションを優先して高速化を実現できる。また、キャッシュ維持時間とタイマを用いた駆動タイミング管理により、キャッシュ維持アプリケーション３０４の負荷を必要最小限に抑えることが可能である。

次に、本発明に係る制御システムのハードウェア構成の他の例を図面に示す。図１８は、Ｌ１キャッシュ１０８もＬ２キャッシュ１１１と同様に、コア外でＣＰＵ内に構成されている例を示すブロック図である。図１９は、Ｌ１キャッシュ１０８とＬ２キャッシュ１１１とも、マルチコアの夫々のコア内に構成されている例を示すブロック図である。図２０は、図１のＬ１キャッシュ１０８とＬ２キャッシュ１１１とに加えて、各コア外でＣＰＵ１０２内にＬ３キャッシュ１１７が追加されている例を示すブロック図である。図２１は、図１９の制御システムの各コア外でＣＰＵ１０２内にＬ３キャッシュ１１７が追加されている例を示すブロック図である。ＣＰＵ１０２がＬ３キャッシュを備える形態では、維持対象データをＬ３キャッシュ１１７に維持するようにしてもよい。

１０１ 制御システム
１０２ ＣＰＵ
１０３ メインメモリ
１０４ 周辺装置
１０５ コア１
１０６ コア２
１０７ コアN
１０８ Ｌ1キャッシュ(コア１内)
１０９ Ｌ1キャッシュ(コア２内)
１１０ Ｌ1キャッシュ(コアN内)
１１１ Ｌ2キャッシュ
３０１ 優先アプリケーション
３０２ 通常アプリケーション
３０３ スケジューリングモジュール
３０４ キャッシュ維持アプリケーション
３０５ 他アプリケーション
３０６ メモリアクセスモジュール
３０７ 維持対象管理モジュール
３０８ 維持対象管理情報
３０９ コア配置管理情報
９０１ 維持依頼管理モジュール
１４０１ 周期/時間管理モジュール
１４０２ タイマ設定モジュール
１４０３ タイマ

Claims (9)

1. データの記憶制御システムであって、
   複数のコントローラを備え、
   前記複数のコントローラのうち第１のコントローラは、所定条件下で他のアプリケーションより優先される少なくとも一つの優先アプリケーションを実行し、
   前記複数のコントローラのうち前記第１のコントローラ以外の他のコントローラである第２のコントローラは、前記優先アプリケーションの実行以前に当該優先アプリケーションの実行のための必要データを、当該優先アプリケーションがアクセス可能なキャッシュメモリに維持させておくようにし、
   前記第２のコントローラは、前記優先アプリケーションが実行される前から前記キャッシュメモリに前記必要データの維持を継続し、前記優先アプリケーションが開始するタイミングで前記必要データの維持を中断する、
   記憶制御システム。
2. メインメモリを備え、
   前記第１のコントローラと前記第２のコントローラは、夫々、マルチコアＣＰＵの各コアであり、
   前記メインメモリは前記必要データの管理情報を有し、
   前記第２のコントローラは当該管理情報に基づいて、前記必要データを前記キャッシュメモリに維持する、
   請求項１記載の記憶制御システム。
3. 前記キャッシュメモリはＬ１キャッシュとＬ２キャッシュとを含み、
   前記第２のコントローラは、前記メインメモリから前記必要データを読み出して前記Ｌ１キャッシュ及び／又はＬ２キャッシュに格納する、
   請求項２記載の記憶制御システム。
4. 前記第１のコントローラと第２のコントローラとは夫々前記Ｌ１キャッシュを備え、当該第２のコントローラは自身のＬ１キャシュに格納された前記必要データを、前記Ｌ２キャッシュを経由して前記第１のコントローラのＬ１キャッシュに維持するようにした、
   請求項３記載の記憶制御システム。
5. 前記第１のコントローラは、前記優先アプリケーションとして複数のアプリケーションを実行でき、
   メインメモリは、当該複数のアプリケーション毎に前記必要データを対応させた管理情報を有し、
   前記第２のコントローラは、前記優先アプリケーションとしての複数のアプリケーションの少なくとも一つのアプリケーションからのリクエストに基づいて、前記管理情報を更新する、
   請求項１記載の記憶制御システム。
6. 前記第２のコントローラは、前記リクエストを発行したアプリケーションを前記管理情報から削除する、
   請求項５記載の記憶制御システム。
7. 前記第１のコントローラは、前記優先アプリケーションとして複数のアプリケーションを実行でき、
   前記メインメモリは、当該複数のアプリケーション毎に前記必要データを対応させた管理情報を有し、
   前記第２のコントローラは、前記優先アプリケーションとしての複数のアプリケーション夫々の優先度に応じて、当該優先度が高いアプリケーションから優先的に前記必要データを前記キャッシュメモリに維持するようにした、
   請求項２記載の記憶制御システム。
8. 前記第１のコントローラは、前記優先アプリケーションとして複数のアプリケーションを実行でき、
   前記メインメモリは、当該複数のアプリケーション毎に前記必要データを対応させた管理情報を有し、
   前記第２のコントローラは、前記優先アプリケーションとしての複数のアプリケーション夫々が起動するまでの時間に応じて、当該複数のアプリケーションに対する前記必要データを前記キャッシュメモリに維持する優劣を決定する、
   請求項２記載の記憶制御システム。
9. 複数のコントローラがデータの記憶のための制御を実行する記憶制御方法であって、
   前記複数のコントローラのうち第１のコントローラは、所定条件下で他のアプリケーションより優先される少なくとも一つの優先アプリケーションを実行し、
   前記複数のコントローラのうち前記第１のコントローラ以外の他のコントローラである第２のコントローラは、前記優先アプリケーションの実行以前に当該優先アプリケーションの実行のための必要データを、当該優先アプリケーションがアクセス可能なキャッシュメモリに維持させておくようにし、
   前記第２のコントローラは、前記優先アプリケーションが実行される前から前記キャッシュメモリに前記必要データの維持を継続し、前記優先アプリケーションが開始するタイミングで前記必要データの維持を中断する、
   記憶制御方法。

Images