JP2012150830A - 限定された誤りによる遅延した更新によるソフトウェアキャッシュ処理 - Google Patents

Abstract

【課題】限定された誤りを可能にしながら、十分なデータコヒーレンシを維持するためのマルチコアシステム又はマイクロプロセッサにおけるソフトウェアキャッシュ方法を提供する。
【解決手段】キャッシュ値の遅延更新によって引き起こされるエラーに耐性のある最適化されたアプリケーション命令を実行する複数のプロセッサ要素を有するシステムと、メインメモリの一部を更新する最適化更新モジュールと、メインメモリの一部を抽出する最適化ロードモジュールとを有し、メインメモリの一部の変化を示す更新フラグは、メインメモリの一部の抽出前に閾値５０４に基づき定期的な間隔でチェックされ、変更を示し、閾値５０４に到達するまで、利用可能な場合はキャッシュメモリから抽出され、メインメモリの一部は、予め最適化されたアプリケーション命令のＩＰＡ（ＩｎｔｅｒＰｒｏｃｅｄｕａｌ Ａｎａｌｙｓｉｓ）の結果に基づき選択される。
【選択図】図５

Description

本発明の実施例は、一般にマイクロプロセッサ計算システムに関し、より詳細には、限定された誤りを可能にしながら、十分なデータコヒーレンシを維持するためのマルチコアシステム又はマイクロプロセッサにおけるソフトウェアキャッシュ処理に関する。

プロセッサ最適化のための各種機構が存在する。具体的には、多数のプロセッサが、あるタイプのキャッシュ処理機構を利用するよう設計されている。キャッシュ処理機構は、メモリアクセス遅延による問題を示す。しばしば、メモリ記憶装置の容量を増大することはそれに係る遅延を増大させる場合がある。従って、より大きなメモリへのアクセスは、より大きな遅延をもたらす。メモリアクセス遅延は、プロセッサの実行パフォーマンスに対して影響を及ぼす。大部分のアプリケーションは、ごく小さなアクセスされるデータセットしかプログラムの実行中に必要とされないという特徴を有している。基本的には、これらの頻繁にアクセスされるメモリは、プロセッサに「より近接して」、すなわち、ハードウェアキャッシュによりもたらされる。

インテルコーポレイションから入手可能なＩＸＰネットワークプロセッサなどのいくつかの特殊な埋め込みプロセッサは、ハードウェアキャッシュを有さない。これらの埋め込みプロセッサは、携帯電話、ＭＰ３プレーヤー及び他の装置において見つけられるかもしれない。これら埋め込みプロセッサについて、キャッシュオンダイ（ｃａｃｈｅ ｏｎ ｄｉｅ）を有するコストはかなりのものになるかもしれない。ネットワークプロセッサは、多数の異なる情報パケットを処理する傾向がある。各パケットは、個別に処理されるかもしれない。より大きなスループット／帯域幅を取得するため、プロセッサダイが、各パケットが異なる埋め込みプロセッサにより処理可能な多数のプロセッサ要素に割り当てられるかもしれない。これらのシステム上でハードウェアキャッシュを実現するのでなく、さらなるプロセッサを有することが好ましいかもしれない。また、他のアプリケーションよりネットワークアプリケーションではロカリティ（ｌｏｃａｌｉｔｙ）が少ないということが信じられている。従って、キャッシュに配置されるべき“頻繁に使用される”データは少ない。

一般的なアプリケーションについて、設計者はソフトウェアキャッシュよりハードウェアキャッシュを内蔵させる傾向がある。既存のシステムでは、ソフトウェアキャッシュ処理は、典型的には、ハードウェアキャッシュ処理ほど良好なパフォーマンスを示さない。一部の研究者は、ソフトウェア制御と共にオンチップメモリを利用することを試みてきた。例えば、１つの論文は以下のように記載している。

“あるデジタル信号処理（ＤＳＰ）チップは、プログラマがアクセス時間を向上させるのに利用可能な小型で高速なオンチップメモリを有する。これらのオンチップメモリはキャッシュではなく、離れたアドレススペースに配置される。このことは、オフチップメモリアドレスとオンチップメモリアドレスとを関連付けする必要性、関連検索（ａｓｓｏｃｉａｔｉｖｅ ｌｏｏｋｕｐ）の必要性及び自動置換の必要性を解消することによって、それらの実現を簡単化する。その代わりに、設計者は、プログラマにタイムリーかつ効率的な方法によりメインメモリとオンチップメモリとの間でデータを移動させる責任を課する。”（Ｋ．Ｄ．Ｃｏｏｐｅｒ及びＴ．Ｊ．Ｈａｒｖｅｙによる“Ｃｏｍｐｉｌｅｒ−Ｃｏｎｔｒｏｌｌｅｄ Ｍｅｍｏｒｙ”（Ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＡＳＰＬＯＳ−ＶＩＩＩ，Ｓａｎ Ｊｏｓｅ，ＣＡ，Ｏｃｔｏｂｅｒ １９９８）を参照されたい。）この研究に記載されている方法は、使用された値を保持する場所としてオンチップメモリの小さな部分又は小さなＣＣＭ（Ｃｏｍｐｉｌｅｒ−Ｃｏｎｔｒｏｌｌｅｄ Ｍｅｍｏｒｙ）の代替的利用を提供している。

既存のプロセッサアーキテクチャは、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やディスクドライブなどの大型であるが低速なメモリに拡張するプロセッサの近傍において、キャッシュなどの小型であるが高速のメモリを有するメモリ階層を利用している。この設計は、頻繁にアクセスされるデータへのメモリアクセス遅延を最小限にしながら、大きなメモリスペースを実現する。

特定のニーズによるアプリケーションに対する特殊なプロセッサアーキテクチャが、重要性を増大させてきている。例えば、上述されるようなインテルＩＸＰプロセッサは、パケットを処理するためルータ内に埋め込まれる。各パケットは他のものから独立に処理可能であるため、１つのＩＸＰプロセッサは、パケットを処理するタスクに専用の多数の軽量なマルチスレッドマイクロエンジン（ＭＥ）コアを有する。Ｘｓｃａｌｅ（登録商標）技術を利用したインテルプラットフォームでは、コントロールプレーンコードを処理するためのＸｓｃａｌｅ（登録商標）コアが存在する。Ｘｓｃａｌｅ（登録商標）は、ＳｔｒｏｎｇＡＲＭ技術から導出される埋め込みマイクロプロセッサアーキテクチャである。ソフトウェアキャッシュは、頻繁に読み書きされるデータをキャッシュしようとする。ＩＸＰのメモリ階層は、各ＭＥ内に小型であるが高速のローカルメモリと、すべてのＭＥの間に共有されるスクラッチパッドメモリ、スタティックＲＡＭ（ＳＲＡＭ）及びＤＲＡＭメモリ（より大きなアクセス遅延の）とを有する。

これらのＭＥは、各コアのサイズを最小化するため、またネットワークアプリケーションのパケットは、キャッシュ処理から恩恵を受ける空間的又は時間的メモリロカリティを有しないということが信じられてきたため、キャッシュなしに設計されてきた。こ仮定は、ネットワークプロセッサが、パケットを単に１回読み、パケットについて作業を実行し、完了すると、単にパケットを送信するという考えから生じたものである。

ソフトウェアにより制御されるキャッシュ処理は、小型であるが高速のローカルメモリを利用することによって、ハードウェアキャッシュなしにデータロカリティから恩恵を受けるための方法として提案されてきた。ここでは、ハードウェアキャッシュ機能は、ソフトウェアルーチンによりエミュレートすることが可能である。ソフトウェアにより制御されるキャッシュ処理は、ソフトウェアオーバーヘッドを最小化するための限定的な特徴により実現可能である。例えば、キャッシュコヒーレンシは、異なるＭＥにキャッシュされたデータのコピーが同一の値を有するアプリケーションにおいて、正確な実行を保証するための必要条件である。しかしながら、既存のシステムでは、ソフトウェア制御されたキャッシュ処理においてキャッシュコヒーレンシをサポートすることはコストがかかり、非効率である。

本発明の課題は、上記問題点に鑑み、限定された誤りを可能にしながら、十分なデータコヒーレンシを維持するためのマルチコアシステム又はマイクロプロセッサにおけるソフトウェアキャッシュ方法を提供することである。

上記課題を解決するため、本発明の一態様は、遅延更新及び限定された誤りによるソフトウェアキャッシュ処理のためのシステムであって、各プロセッサ要素が通信可能にメインメモリとキャッシュメモリとに接続され、キャッシュ値の遅延更新によって引き起こされるエラーに耐性のある最適化されたアプリケーション命令を実行する複数のプロセッサ要素を有するシステムと、メインメモリの一部を更新する最適化更新モジュールと、前記メインメモリの一部を抽出する最適化ロードモジュールとを有し、前記更新は、前記メインメモリの一部の変化を示すよう更新フラグを設定し、前記更新フラグは、前記メインメモリの一部を抽出する前に閾値に基づき定期的な間隔によりチェックされ、前記メインメモリの一部は、前記更新フラグが変更を示し、前記閾値に到達するまで、利用可能である場合には、キャッシュメモリから抽出され、前記メインメモリの一部は、予め最適化されたアプリケーション命令のＩＰＡ（ＩｎｔｅｒＰｒｏｃｅｄｕａｌ Ａｎａｌｙｓｉｓ）の結果に基づき選択される、システムに関する。

本発明によると、限定された誤りを可能にしながら、十分なデータコヒーレンシを維持するためのマルチコアシステム又はマイクロプロセッサにおけるソフトウェアキャッシュ方法を提供することができる。

図１は、本発明の実施例により利用可能なネットワークアプリケーションにおけるパケット転送のための一例となるｔｒｉｅテーブルを示す。 図２は、グローバルデータを共有するための最適化されていないアクセスを示す。 図３は、本発明の実施例によるソフトウェアキャッシュの最適化されたアクセスのためのフロー図である。 図４は、本発明の実施例によるアプリケーションコードを最適化するための一例となるシステムのブロック図である。 図５は、本発明の実施例によるアプリケーションプロファイアを利用してアプリケーションコードを最適化する一例となるシステムのブロック図である。 図６は、本発明の実施例によるランタイム時に実行されるエラーレート解析を示すブロック図である。

本発明の実施例は、限定された誤りによる遅延した更新によるソフトウェアキャッシュ処理に関するシステム及び方法である。本発明の実施例は、メモリアクセス遅延を低減し、キャッシュされた値の遅延した更新により生じる誤りに耐性のあるドメイン固有アプリケーションに対するスループットを向上させるのに利用可能な遅延更新ソフトウェア制御キャッシュについて記載する。本発明の少なくとも１つの実施例では、ソフトウェアキャッシュ処理は、メモリにアクセス及び／又は更新する必要があるアプリケーションプログラムにおいてキャッシュ処理コードを自動生成するため、コンパイラを利用することによって実現可能である。ここに記載されるようなソフトウェアキャッシュ処理は、ハードウェアコストなしにハードウェアキャッシュ処理の効果のいくつかをもたらすかもしれない。ハードウェアキャッシュによる１つの問題点は、キャッシュコヒーレンシである。これは、キャッシュが複数のプロセッサを有するシステムにおいて使用されるとき、キャッシュに問題となる。この問題は、デスクトップシステム、マルチプロセッサシステム、多数の処理要素を有するネットワークプロセッサ及びマルチコアシステムなどの複数のプロセッサを有する他のシステムに該当する。以下の説明の簡単化のため、「マルチプロセッサ」という用語の使用は、マルチプロセッサシステム、多数の処理要素を有するネットワークプロセッサ、及びマルチコアシステムなどの複数のプロセッサを有する他のシステムを意味するのに利用される。

明細書における本発明の「一実施例」又は「実施例」という表現は、当該実施例に関して記載される特定の機能、構成又は特徴が、本発明の少なくとも１つの実施例に含まれることを意味する。従って、明細書を通じて各種部分に出現する「一実施例では」という表現は、必ずしもすべてが同一の実施例を参照しているとは限らない。

説明のため、具体的な構成及び詳細が、本発明の完全な理解を提供するため与えられる。しかしながら、本発明の実施例がここに与えられた具体的な詳細なしに実現されてもよいということは、当業者には明らかであろう。さらに、周知の特徴は、本発明を不明りょうにしないように省略又は簡単化されてもよい。本記載を通じて、各種実施例が与えられるかもしれない。これらは、単に本発明の特定の実施例の記載である。本発明の範囲は、与えられた実施例に限定されるものではない。

キャッシュコヒーレンシは、プロセッサに近接してキャッシュされたデータのコピーについて、すなわち、キャッシュ又はオンチップメモリにおいて、ホーム又はもとのメモリ位置において同一の値を維持する必要がある。キャッシュコヒーレンシは、多数のプロセッサが存在するときには困難なものとなる。

複数のプロセッサによりキャッシュコヒーレンシを提供するためのバスプロトコルが開発されてきた。例えば、ＭＥＳＩ（Ｍｏｄｉｆｉｅｄ Ｅｘｃｌｕｓｉｖｅ Ｓｈａｒｅｄ ａｎｄ Ｉｎｖａｌｉｄ）プロトコルが利用されてきた。キャッシュラインは、マルチプロセッサシステム内でキャッシュがどのように存在するか記述する各種状態にあるかもしれない。例えば、ある状態は、複数のプロセッサがキャッシュから読み込まれていることを意味する“ｓｈａｒｅｄ”であるかもしれない。キャッシュは、データがプロセッサにより変更されている間は“ｅｘｃｌｕｓｉｖｅ”の状態にあるかもしれない。これらの変更は、状態を通信することによって他のプロセッサに通信される。これらのプロセッサは、時間と実現するためのハードウェアに関してコストが大きい。

すべてのプロセッサについて、特に埋め込み又は特殊なアプリケーションに使用されるものについて、ハードウェアキャッシュ機構が利用されなくてもよい。例えば、ＩＸＰプロセッサは、ハードウェアキャッシュを有しない。これらのネットワークプロセッサは、キャッシュ処理の機会を予想しない複数のプロセッサにより構成される。キャッシュ処理の機会は、処理対象のパケットによってではなく、アプリケーションデータ構造によるネットワークプロセッサにおいて存在するかもしれない。例えば、キャッシュすることが望ましい頻繁に使用されるデータは、ルーティングテーブル情報である。

ある実施例では、ハードウェアキャッシュを有しないシステム及びマルチプロセッサシステムにおいてキャッシュ処理機構を利用するため、遅延更新ソフトウェア制御キャッシュが実現される。遅延更新は、プロセッサが更新されたデータがメモリから抽出されるまでのある期間に、キャッシュの古いデータにアクセスすることを可能にするかもしれない。遅延更新ソフトウェア制御キャッシュを適用することは、メモリアクセスを最適化することに役立つかもしれない。この技術の実施例を実現するためのアプリケーションコードに対する最適化は、プログラマによる手動により、又は最適化コンパイラのパスを介し適用されてもよい。

遅延更新キャッシュは、コヒーレンシを定期的にチェックするが、すべての関連するアクセスについては必ずしもチェックしない。ネットワークアプリケーションでは、例えば、データ構造の変更は、１００パケット又は１，０００パケット毎にのみチェックするようにしてもよい。このようなキャッシュ処理は、キャッシュされている値に対する更新の変更を検出するため、低減したメモリアクセスからメモリパフォーマンスを向上させるかもしれない。この最適化は、エラーレートの増大を生じさせるかもしれない。この結果、それは、予想されるエラーレートが小さいとき、又はエラーが重要でないときに限って適用されるべきである。エラーは更新の遅延伝搬から生じする可能性があるため、頻繁に読み込まれるが、頻繁には更新されないデータ構造については、低いエラーレートを生じさせることとなる。本発明の実施例による最適化コンパイラでは、プロファイリングからの結果は、当該動作を有するデータ構造を選択することを助けるかもしれない。

ネットワークアプリケーションでは、読み書き両方が行われるが、明示的なロックによってプロテクトされていない共有されたグローバルデータ構造は、遅延した更新のキャッシュ処理の候補とみなされるかもしれない。メモリパフォーマンスを向上させるため、しばしばロックは省略される。共有メモリへの同時的な読み込みと書き込みの精度は、注意深い符号化により保証されない。アトミックなメモリライトから、同期が非明示的に実現される。アトミックライト（ａｔｏｍｉｃ ｗｒｉｔｅ）とは、メモリアドレス（３２ビットなど）がメモリライトにより常に完全に変更されることを意味する。そのうちの１／２が書き込まれ、その後に当該書き込みが失敗又は中断する可能性があるというケースはない。特定の命令のアトミック性（ａｔｏｍｉｃｉｔｙ）の概念は、マルチプロセッサシステムにおいてコヒーレンシを維持するための基礎となる。遅延更新キャッシュでは、このアトミックライトは、遅延更新の可視化のみにより同期ポイントとして機能するかもしれない。

ここで、図面、特に図１を参照するに、ネットワークアプリケーションにおけるパケット転送のためのｔｒｉｅテーブルが示される。従来の仮定と反対に、ネットワークアプリケーションは、重要なロカリティを有しているかもしれないが、ロカリティは処理されるパケットにおいてではなく、アプリケーションデータ構造において出現する。従って、やや静的なルーティングテーブルに関するキャッシュ処理データ構造は、効果を与えるかもしれない。ネットワークルータのｔｒｉｅテーブル１００は、ノード（丸印）とコネクタ（矢印）により表される。“ｔｒｉｅ”は、バイナリサーチツリーの一種として当該技術で知られている。“ｔｒｉｅ”という用語は、以前から使用されているものであり、“Ｒｅｔｒｉｅｖａｌ”の短縮形である。ｔｒｉｅテーブル１００は、パケットのソース及びデスティネーションアドレスの検索に基づき、パケットがどこに送信されるべきか規定する。例えば、ノード１０１はトップ又はエントリノードである。マッチした文字列に応じて、次のノードが“００”にマッチするノード１０３であるかもしれない。

新たなルーティングエントリ１１１によりｔｒｉｅテーブル１００を更新するため、ライブテーブルに接続することなく、まず新たなノード１０９が占用される。この新たなノード１０９へのポインタがテーブルに書き込まれるときに限って、ライブのｔｒｉｅテーブルに更新が反映される。この単一のポインタ更新は、新たなルーティングエントリのアトミックな同期ポイントとして機能するかもしれない。これは、破線の矢印１１０により示される。

ルータは、パケットを送信する場所を決定するため、このテーブルのコピーを必要とする。この一例となるｔｒｉｅテーブルは、最小のマッチングプリフィックステーブルとして利用されてもよい。ネットワークパケットがルーティングされるとき、インターネットプロトコル（ＩＰ）アドレスが、パケットをそれのデスティネーションに送信するのに利用される。最長マッチングプリフィックステーブルでは、プリフィックスはビット列であり、最長のマッチングビット列が、テーブルのエントリにマッチするため検出される。マッチングエントリが検出されない場合、パケットをルーティングするのにより短いものについてデフォルトが存在する。ｔｒｉｅテーブルは、それがＩＰアドレスを表すときには大変大きなものになるかもしれない。

ネットワークルーティングｔｒｉｅテーブルをソフトウェアによりキャッシュする機会が存在するかもしれない。トップエントリは、すべてのパケットについて頻繁にヒットする。ルータテーブル全体はキャッシュされないが、テーブルの最も頻繁に使用される部分をキャッシュすることは効果的である。

パケットルーティングでは、ルータはあるエラーレートを許容するかもしれない。ルーティングミスされた又はルーティングされなかったパケットは、当該エラーの通知により再送されるようにしてもよい。ルータテーブルは、頻繁に更新されなくてもよい。従って、ネットワークルータは、短時間により古いデータにより機能することが可能である。ネットワークプロトコルは、これらのルーティングエラーを許容するよう設計されている。また、パケットがルーティングミスされた場合、このラインのさらに下位のルータが更新情報を有し、その適切なデスティネーションにパケットを良好にルーティングし、これにより、サービスの中断が生じなくなるかもしれない。

ある実施例では、後述されるような式が遅延更新を制御するのに利用可能である。

一実施例では、ルータテーブルに対してコヒーレンシチェックを実行するため、コードがコンパイラにおいて生成されるかもしれない。本実施例では、所望のエラー限定レート（ｒ_{ｅｒｒｏｒ}）が選択される。テーブルがチェックされるレート（ｒ_{ｃｈｅｃｋ}）は、既知又は推定されてもよい。チェックレートは、３つの入力ｒ_ｓｔ、ｒ_ｌｄ及びｒ_{ｅｒｒｏｒ}の関数である。ここで、ｒ_ｓｔはストアのレートであり、ｒ_ｌｄはロードのレートであり、ｒ_{ｅｒｒｏｒ}は最大許容エラーレートである。“ロード”はデータの読み込みであり、“ストア”とはデータの書き込み又は更新である。最大許容エラーレートは、ストアレートと１からチェックレートを減算したものとの積をロードレートにより除算したもの以下であるとして定義されるかもしれない。チェック頻度は、最大許容エラーレートとロードレートとの積をストアレートにより除算したものを１から差し引いたもの以下として定義されてもよい。

遅延更新キャッシュ処理に適用する上記確率は、ＩＰＡ（Ｉｎｔｅｒ−Ｐｒｏｃｅｄｕａｌ Ａｎａｌｙｓｉｓ）サポートを有するコンパイラにより特定されてもよい。ＩＰＡは、ロックによりプロテクトされていないが、読み書きされるグローバル変数を決定するようにしてもよい。

メモリプロファイリングからの結果（又は他の解析又はモニタリング機構）と組み合わせて、ＩＰＡの上記結果は、遅延更新キャッシュから最も良く恩恵を受けるグローバル変数を特定することができる。

一般的なネットワークアプリケーションをサーベイして、本発明者は、頻繁に読み込まれるが、頻繁には書き込みされない多くのグローバルデータ構造を発見した。この読み込みは、パケット処理コアからのものであるが、頻度の低い書き込みは、一般には新たなテーブルエントリを追加するため、又は共有される統計量を更新するため、ユーザ制御されるコアからものものである。当該動作を示すデータ構造の具体例が、テーブル１にリストされる。

これらの構成は、しばしばロッキングの高いＩ／Ｏコストにより、ロックによってはプロテクトされない。むしろ、それらはライト更新の精度を保証するため、アトミックライトに頼る。

通常は非従来的なものと考えられるかもしれない観察された性質は、キャッシュされたコピーに対する更新の通信が、これらの構成ではしばしば遅延する可能性があるということである。ネットワークアプリケーションなどのドメイン固有アプリケーションでは、キャッシュされたコピーにすぐには伝搬されなかった更新された共有データ構造から生ずる偶発的なエラーは許容されうる。テーブル２において、ネットワークアプリケーションの具体例に通手の可能性のあるエラーの具体例が示される。ネットワークアドレス変換（ＮＡＴ）及びパケット転送アプリケーションでは、パケットがときどき不正確にルーティングされる可能性があると仮定することが妥当である。ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）サポートを有するルータのフローパラメータは、長期的な平均が正しく振る舞う限り、ユーザにより規定されるフローの更新中、短期的には若干乖離するかもしれない。

アプリケーションのドメインとして、ネットワークプログラムは、典型的には多数のソースからのエラーを処理するよう構成される。実際に、多くの一般的なネットワークアプリケーションにおいて、パケット処理エラーが非明示的に利用される。物理レイヤイーサネット（登録商標）は、パケット衝突を特定するためエラーを検出する必要がある。ＴＣＰ（Ｔｒａｎｓｆｅｒ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）は、パケットが受信者に到達したことを保証するため、受信者による送信されたパケットのアクノリッジメント（ＡＣＫ）を要求する接続指向のプロトコルである。（例えば、Ｗ．Ｒ．Ｓｔｅｖｅｎｓによる“ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ Ｖｏｌ．１”（Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ，１９９４）を参照されたい。）送信者がＡＣＫを受信できないと、アクノリッジされていないパケットの再送が行われる。ＱｏＳルータは（スケジューリング及びメータリングアルゴリズムを介し）、帯域幅を所定のフローに割り当てるため、パケットを明示的に削除する。（例えば、Ｓ．Ｆｌｏｙｄ及びＶ．Ｊａｃｏｂｓｏｎによる“Ｒａｎｄｏｍ Ｅａｒｌｙ Ｄｅｔｅｃｔｉｏｎ Ｇａｔｅｗａｙｓ ｆｏｒ Ｃｏｎｇｅｓｔｉｏｎ Ａｖｏｉｄａｎｃｅ”（ＩＥＥＥ／ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｎｅｔｗｏｒｋｉｎｇ，Ａｕｇｕｓｔ，１９９３）を参照されたい。）
図２は、共有グローバルデータへの最適化されていないアクセスを示す。頻度の低いライトパス２１０は、共有データ２２０にあるルーティングテーブルを更新する。頻度の低いリードパス２３０は、パケットを処理するとき、各パケットプロセッサにより実行される。ルーティングされるすべてのパケットは、共有メモリのテーブル構成へのアクセスを生じさせる。一例では、ルーティングテーブルが更新されると、ｇｌｏｂａｌ＿ｄａｔａ２２１が、ｇｌｏｂａｌ＿ｄａｔａ２２１の共有データエリア２２０に格納される（２１１）。アプリケーションによりルーティングテーブルが読み込まれると（２３１）、共有データがｇｌｏｂａｌ＿ｄａｔａ２２１から抽出される。

図３は、本発明の実施例によるメモリパフォーマンスを向上させるため、キャッシュコヒーレンスが遅延許容グローバルデータにどのように緩和されるかを示す最適化されたアクセスシーケンスのブロック及びフロー図を示す。本発明の実施例は、複数のプロセッサ３５０が共有データにアクセスすることによって実行するよう構成される。これらのプロセッサは、マルチプロセッサシステム、多数の処理要素を有するネットワークプロセッサ、及びマルチコアシステムなどの複数のプロセッサを有する他のシステムであってもよい。ｇｌｏｂａｌ＿ｄａｔａ３０５は、マルチプロセッサ及びマルチコアシステムのプロセッサ３５０間に共有される。この図では、実線の垂直の矢印は、リード／ロード及びライト／ストアモジュールの一時的な実行を示す。破線の矢印は、リード及びライトモジュールによる共有データへのアクセスを示す。本発明の実施例では、データに対する更新は、データのアクセスと比較して、頻繁には行われない。データが頻度の低いライトパス３００においてプロセッサｎにより更新されるとき、更新されたデータはｇｌｏｂａｌ＿ｄａｔａ３０５として共有メモリに格納される（３０１）。その後、ｕｐｄａｔｅ＿ｆｌａｇが、ｔｒｕｅに設定され（３０３）、共有メモリに格納される（３０７）。

ネットワークプロセスは、更新のチェック前に何回かキャッシュから要求されたデータにアクセスし続けるかもしれない。このことは、アプリケーションがあるエラーレートを許容することができるため可能である。ローカルカウンタｃｏｕｎｔが、データ構造へのアクセスを追跡するため利用される。プロセッサｍのリードパス３１０は、ｃｏｕｎｔが指定された閾値（ｔｈｒｅｓｈｏｌｄ）より大きいか判定する（３１１）。大きい場合、ｃｏｕｎｔはゼロにリセットされる（３１３）。ｕｐｄａｔｅ＿ｆｌａｇ３０７は、共有メモリ又は他の指定された位置からロードされる。ある実施例では、ｕｐｄａｔｅ＿ｆｌａｇはシステムレジスタに存在する。他の実施例では、ｕｐｄａｔｅ＿ｆｌａｇはコントロールラインにより設定される。ｇｌｏｂａｌ＿ｄａｔａが３１５において決定されたように、更新されている場合、キャッシュはクリアされる（３１９）。ｕｐｄａｔｅ＿ｆｌａｇもまたクリアされる。その後、ｃｏｕｎｔが３２１においてインクリメントされ、更新されたデータが共有メモリからロードされる。ｃｏｕｎｔが、３１１において決定されるように、ｔｈｒｅｓｈｏｌｄより大きくない場合、又は３１５において決定されるように、更新がない場合（ｕｐｄａｔｅ＿ｆｌａｇがｆａｌｓｅに等しい）、利用可能である場合には、データが単にキャッシュ３１７からロードされる。データが現在キャッシュにない場合、従来の方法は、共有メモリからデータを自動抽出するため利用されてもよい。

プロセッサｎとｍは、同一のプロセッサであってもよいということが当業者に明らかである。すなわち、ｇｌｏｂａｌ＿ｄａｔａからのリードを実行するプロセッサｍが実際に同一のプロセッサであることが、頻度の低いライトパスにおいてプロセッサｎにより実行される更新中に複数回あるかもしれない。

頻繁に読み込まれるデータがキャッシュメモリに配置されるというポリシーは、本発明の実施例に適応するよう変更される必要はないということは、当業者に明らかである。ｕｐｄａｔｅ＿ｆｌａｇを利用してプロテクトされるべきｇｌｏｂａｌ＿ｄａｔａは、データ構造全体又はデータ構造の一部であってもよい。何れかの時点において、プロテクトされたデータ構造又はその一部が、共有メモリ又はさらにキャッシュにも存在してもよい。メモリは、データがメモリ又はキャッシュから抽出されるか制御するソフトウェアハンドラを有するようにしてもよい。ある実施例では、ｕｐｄａｔａ＿ｆｌａｇを設定し、ｔｈｒｅｓｈｏｌｄをチェックするためロープを挿入する追加的なコードが、コンパイル期間中にネットワークコードに挿入されてもよい。

キャッシュは、タグアレイ及び実際のライン又は値を有するかもしれない。タグアレイは、アドレスを有する。キャッシュされた値がアドレスについてリクエストされると、タグアレイがマッチングアドレスについてチェックされる。タグアレイにマッチがある場合、ラインがキャッシュからプルされる。データを抽出するため、メインメモリを訪れる必要がある。その後、最近抽出されたデータのスペースを生成するため、あるアイテムがキャッシュから取り除かれる。ハードウェアキャッシュでは、このプロセスはコントロールラインにより実行される。ソフトウェアキャッシュにより、ソフトウェアハンドラは、ハードウェアでなくキャッシュへのアクセスを制御する。メモリにアクセスするためのアプリケーションコードは、上述のような追加的なコードラインを挿入するためコンパイルされる。ソースコードがＬＯＡＤを示す毎に、３１０に記載されるようなチェック閾値ループが、実行可能なコードに挿入される。ＳＴＯＲＥが示される毎に、コンパイラは、３００において説明されるように、ｕｐｄａｔｅ＿ｆｌａｇを設定するためコードを挿入する。コンパイラは、ｕｐｄａｔｅ＿ｆｌａｇが存在する場所の表示によりカスタマイズされ、これにより、適切なコードが生成されるかもしれない。ｔｈｒｅｓｈｏｌｄがまた決定され、ループが所望の閾値により生成されるように、コンパイラに知らされる。デフォルトの閾値は、コンパイラにおいてハードコード化され、任意的に上書きされてもよい。実施例では、ｔｈｒｅｓｈｏｌｄは、オン・ザ・フライ（ｏｎ−ｔｈｅ−ｆｌｙ）に設定され、コードが実行されるときに抽出される動的変数であってもよい。この閾値は、実行時間中にアプリケーションコードにアクセス可能なメモリ、システムレジスタ又は他の何れかの場所に配置されてもよい。従って、オペレータがエラーレートが高すぎると判断した場合、ｔｈｒｅｓｈｏｌｄはシステムをオフラインにすることなく引き下げられる。

図４は、本発明の実施例によるアプリケーションコードを最適化する一例となるシステムを示すブロック図である。最適化４０１を要求する更新遅延エラー許容アプリケーションは、ｇｌｏｂａｌ＿ｄａｔａを更新及びアクセスするためＳＴＯＲＥ４１３とＬＯＡＤ４１５命令によるソースコード４１１を有するかもしれない。アプリケーションソースコードは、最適化された実行可能４０５を生成するため、最適化コンパイラ４０３によりコンパイルされる。ある実施例では、最適化コンパイラは、ＳＴＯＲＥ命令が特定されると更新コードを生成する更新コード生成モジュール４３３と、ＬＯＡＤ命令４１５が特定されると拡張されたロードコードを生成するロードコード生成モジュール４４３とを有するようにしてもよい。最適化コンパイラは１つのモジュールに合成される更新及びロードコード生成のためのモジュールにより実現されてもよいし、又は独立したモジュールにより実現されてもよいということは、当業者に明らかである。

ある実施例では、更新コード生成モジュール４３３とロードコード生成モジュール４４３とは、もとのアプリケーションコードにおいてＳＴＯＲＥ４１３とＬＯＡＤ４１５の命令を特定する。ＳＴＯＲＥ４１３の命令とＬＯＡＤ４１５の命令は、最適化されたコード４２０のキャッシュコヒーレンシと更新遅延を処理するためのさらなる命令を有するようコンパイルされる。ＳＴＯＲＥ命令は、ＳＴＯＲＥ命令とｕｐｄａｔｅ＿ｆｌａｇ ＳＥＴ命令４２１の両方を含むよう拡張されるかもしれない。ＬＯＡＤ命令は、図３について説明されるように、ループ４２３に等価なコンパイルされたコードに拡張されてもよい（３１０）。

図５は、本発明の実施例によるアプリケーションプロファイラを利用してアプリケーションコードを最適化する一例となるシステムを示すブロック図である。アプリケーションソースコード５０１は、メモリ又はアプリケーションプロファイラ５０２を介してわたされる。いくつかの実施例では、メモリプロファイラは、最適化コンパイラの一部であってもよい。プロファイラは、何れの頻繁に使用されるデータが更新遅延を受けるべきか決定するのに利用するため、解析を実行するようにしてもよい。ある実施例では、アプリケーションプロファイラが、何れのグローバル変数５０６が共有メモリに最も良く配置されるか、すなわち、頻繁にアクセスされるが、頻繁には更新されないか決定する。プロファイラはまた、妥当な閾値５０４を決定するようにしてもよい。実施例では、閾値５０４はアプリケーションコードにおける許容されるエラーレート、ロード及びストアに基づくものであってもよく、オフラインに決定されるか、又はアプリケーションプロファイラによって決定されるのではなく動的に選択可能であってもよい。グローバル変数の選択５０６と閾値情報５０４が、最適化コンパイラ５０３に供給されてもよい。アプリケーションソースコード５０１は、最適化されたコンパイルされたコード５０５を生成するため、最適化コンパイラ５０３を介してわたされる。ある実施例では、最適化コンパイラは、図４に関して説明されたように、更新コード生成モジュール５３３とロードコード生成モジュール５４３とを有する。

実施例では、最適化コンパイラはさらに、ＩＰＡモジュール５５３を有する。いくつかの実施例では、最適化コンパイラはさらに、マシーンに独立した最適化、ループネスト最適化及び／又はコード生成（図示せず）を有する。ＩＰＡモジュール５５３からの結果は、遅延更新キャッシュから最も良く恩恵を受けるグローバル変数を特定するため、メモリプロファイリング５０２（又は他の解析又はモニタリング機構）からの結果と組み合わされてもよい。ＩＰＡは、読み書きされるが、ロックによってはプロテクトされないグローバル変数を決定するようにしてもよい。閾値５０４は、実行期間中は動的に更新され、又は静的なものであってもよい。

説明されたシステムと方法の実施例は、ネットワークルーティング以外のアプリケーションに利用可能であるということが当業者に明らかであろう。例えば、画面又は表示レンダリングに対する実施例が利用されてもよい。いくつかのケースでは、計算システムにおけるグラフィックス又は他の画面要素における正のエラーレートを許容することは許容可能であるかもしれない。この場合、ユーザは、データ更新フラグがチェックされるまで短時間の間、更新されていないピクセル又は画面部分を見るかもしれない。この画面部分は、計算システム上のアプリケーションプログラムの処理に対して重要なものではないかもしれない。エラー許容アプリケーションの他の実施例が実現されてもよい。

ある実施例では、閾値がゼロに設定される場合、更新フラグが処理ループを介した各パスについてチェックされる。エラー許容度が低いと判明したアプリケーションは、閾値をこのレベルに設定される。いくつかの実施例では、閾値は、予想されるトラフィック及び更新に適応するため、その日又はその週の間の所定の回数各値に設定及びリセットされる。エラー許容度が低い他のアプリケーションはまた、記載したシステム及び方法を利用して実現されてもよい。例えば、重要な計算が最初に実行されるように、アプリケーションは計算の重要度を重み付けし、キャッシュ抽出にエラーを生じさせる傾向のある重要でない計算は削除され、より重要な計算が最初に実行される。このことは、計算ストレスの期間中のパフォーマンスとエラーレートとの間のトレードオフを実現可能にするかもしれない。

ある実施例では、与えられたデータブロックについて１つの共有メモリユニットが存在し、各プロセッサは自らのオンボードキャッシュを有する。他の実施例では、プロセッサの一部のみがオンボードキャッシュを有する。オンボードキャッシュを有しないプロセッサは、アクセスが要求される毎に、メイン（共有）メモリにアクセスする。

図６は、誤り解析に基づく閾値の動的更新を示すブロック図である。本発明の実施例では、エラーレート解析モジュール６０１は、ランタイム時に動作する。エラーレート解析モジュール６０１は、共有メモリ３０５と同期しないキャッシュデータを利用するプロセッサ３５０に関連するエラーに係るメトリックをキャプチャする。エラーレートが高すぎる（低すぎる）と判断される場合、エラーレート解析モジュールは、最適化されたアプリケーションコードに使用される閾値６０３を自動更新する。閾値６０３は、プロセッサ３５０上で実行される最適化されたアプリケーションコードに直接的に利用可能なランタイム変数であってもよい。他の実施例では、誤り解析は手動により実行されてもよい。さらなる実施例では、アプリケーションコードは、閾値がコンパイラにおいてハードコード化されている場合には、再コンパイル及び再最適化される必要があるかもしれない。他の実施例では、閾値６０３は、次のコンパイル処理のための入力として最適化コンパイラ５０３に自動送信されるかもしれない。

ここに記載される技術は、特定のハードウェア又はソフトウェアコンフィギュレーションに限定されるものではなく、それらは何れかの計算、家電機器又は処理環境において適用可能性を見出すかもしれない。当該技術は、ハードウェア、ソフトウェア又は上記２つの組み合わせにより実現可能である。当該技術は、モバイル又は固定式コンピュータ、携帯情報端末、セットトップボックス、携帯電話及びページャ、家電機器（ＤＶＤプレーヤー、パーソナルビデオレコーダ、パーソナルビデオプレーヤー、衛星受信機、ステレオ受信機、ケーブルテレビ受信機を含む）及び１以上のプロセッサ、プロセッサによりアクセス可能な記憶媒体（揮発性及び不揮発性メモリ及び／又はストレージ要素を含む）、少なくとも１つの入力装置及び１以上の出力装置を含む他の電子装置など、プログラム可能なマシーン上で実行されるプログラムにより実現可能である。プログラムコードは、上述した機能を実行し、出力情報を生成するため入力装置を利用して入力されるデータに適用される。出力情報は、１以上の出力装置に適用されてもよい。当業者は、本発明がマルチプロセッサシステム、ミニコンピュータ、マインフレームコンピュータ、独立した家電機器などを含む各種システムコンフィギュレーションにより実現可能であるということを理解するであろう。本発明はまた、タスク又はその一部が通信ネットワークを介しリンクするリモート処理装置によって実行可能な分散化された計算環境において実現可能である。

各プログラムは、処理システムと通信するため、ハイレベルの手続的又はオブジェクト指向プログラミング言語により実現されてもよい。しかしながら、プログラムは、所望される場合には、アセンブリ又はマシーン語により実現されてもよい。何れのケースでも、言語はコンパイル又はインタープリットされる。

プログラム命令は、命令によりプログラムされる汎用又は特定用途向け処理システムにここに記載される処理を実行させるのに利用可能である。あるいは、当該処理は、処理を実行するための配線ロジックを有する特定のハードウェアコンポーネント、又はプログラムされたコンピュータコンポーネントとカスタムハードウェアコンポーネントとの何れの組み合わせによって実行されてもよい。ここに記載される方法は、処理システム及び当該方法を実行する他の電子装置をプログラムするのに利用可能な命令を格納したマシーンアクセス可能媒体を有するコンピュータプログラムプロダクトとして提供されてもよい。ここで使用される“マシーンアクセス可能な媒体”という用語は、以下に限定されるものではないが、ソリッドステートメモリ、光及び磁気ディスク、データ信号を符号化する搬送波を含む。さらに、アクションを実行させ、又は結果をもたらすものとして１形態又は他の形態によるソフトウェア（プログラム、プロシージャ、プロセス、アプリケーション、モジュール、ロジックなど）を言及することは、当該分野において一般的である。このような表現は、処理システムによるソフトウェアの実行が結果を生成するアクションをプロセッサに実行させることを記載する単なる略式な方法である。

本発明が例示的な実施例を参照して説明されたが、本記載は限定的な意味に解釈されるべきでない。本発明が属する技術分野の当業者に明らかな本発明の他の実施例と共に、例示的な実施例の各種変更が、本発明の趣旨及び範囲内に属するものとみなされる。

１０１，１０３ ノード

Claims (15)

1. 遅延更新及び限定された誤りによるソフトウェアキャッシュ処理のためのシステムであって、
   各プロセッサ要素が通信可能にメインメモリとキャッシュメモリとに接続され、キャッシュ値の遅延更新によって引き起こされるエラーに耐性のある最適化されたアプリケーション命令を実行する複数のプロセッサ要素を有するシステムと、
   メインメモリの一部を更新する最適化更新モジュールと、
   前記メインメモリの一部を抽出する最適化ロードモジュールと、
   を有し、
   前記更新は、前記メインメモリの一部の変化を示すよう更新フラグを設定し、
   前記更新フラグは、前記メインメモリの一部を抽出する前に閾値に基づき定期的な間隔によりチェックされ、
   前記メインメモリの一部は、前記更新フラグが変更を示し、前記閾値に到達するまで、利用可能である場合には、キャッシュメモリから抽出され、
   前記メインメモリの一部は、予め最適化されたアプリケーション命令のＩＰＡ（ＩｎｔｅｒＰｒｏｃｅｄｕａｌ Ａｎａｌｙｓｉｓ）の結果に基づき選択される、システム。
2. 前記閾値は、前記更新フラグをチェックする前に実行されるべき最大ロード数を特定する、請求項１記載のシステム。
3. 前記閾値は、アプリケーションプロファイラによって決定される、請求項２記載のシステム。
4. 前記閾値は、最適化前の最適化された命令におけるロード数及びストア数と、許容可能な最大エラーレートとの関数である、請求項３記載のシステム。
5. 遅延更新及び限定された誤りによるソフトウェアキャッシュ処理のための最適化されたアプリケーションによって実行される方法であって、
   データの選択された部分の変更に応答して、前記最適化されたアプリケーションにより共有メモリの前記データの選択された部分を更新するステップと、
   前記データの選択された部分をロードするステップと、
   を有し、
   前記更新するステップはさらに、更新が行われたことを示すフラグを設定し、
   前記最適化されたアプリケーションは、メモリパフォーマンスを向上させるため、更新されていないキャッシュメモリからの古いデータの限定的な抽出を許可するための許容可能なエラーレートを許容することによって、遅延に耐性のあるグローバルデータのキャッシュコヒーランスを緩和するようコンパイラにより最適化されたアプリケーションであり、
   前記データの選択された部分は、前記更新フラグが更新が行われたことを示さず、かつ前記許容可能なエラーレートに基づき選択された閾値に到達していない場合、キャッシュメモリから抽出され、
   前記更新フラグが更新が行われたことを示し、前記選択された閾値に到達しているとき、前記データの選択された部分が前記共有メモリから抽出され、
   前記データの選択された部分は、予め最適化されたアプリケーション命令のＩＰＡ（Ｉｎｔｅｒ−Ｐｒｏｃｅｄｕａｌ Ａｎａｌｙｓｉｓ）の結果に基づき選択される、方法。
6. 前記選択された閾値は、前記更新フラグのチェック前に実行される最大ロード数を特定する、請求項５記載の方法。
7. アプリケーションプロファイラによって前記閾値を決定するステップをさらに有する、請求項６記載の方法。
8. 前記閾値は、最適化前の前記最適化されたアプリケーションにおけるロード数及びストア数と、許容可能な最大エラーレートとの関数である、請求項７記載の方法。
9. 遅延更新及び限定された誤りによるソフトウェアキャッシュ処理のための命令を有するマシーンアクセス可能な記憶媒体であって、
   前記命令は、アクセス時にマシーンに前記マシーン上で実行される最適化されたアプリケーションに、
   共有メモリの選択されたデータ部分を更新することによって、前記選択されたデータ部分の変更に応答させ、
   前記選択されたデータ部分をロードさせ、
   前記更新はさらに、更新が行われたことを示すフラグを設定し、
   前記最適化されたアプリケーションは、メモリパフォーマンスを向上させるため、更新されていないキャッシュメモリからの古いデータの限定的な抽出を許可するための許容可能なエラーレートを許容することによって、遅延に耐性のあるグローバルデータのキャッシュコヒーランスを緩和するようコンパイラにより最適化されたアプリケーションであり、
   前記選択されたデータ部分は、前記更新フラグが更新が行われたことを示さず、かつ前記許容可能なエラーレートに基づき選択された閾値に到達していない場合にキャッシュメモリから抽出され、
   前記更新フラグが、更新が行われたことを示し、前記選択された閾値に到達しているとき、前記選択されたデータ部分が前記共有メモリから抽出され、
   前記選択されたデータ部分は、予め最適化されたアプリケーション命令のＩＰＡ（Ｉｎｔｅｒ−Ｐｒｏｃｅｄｕａｌ Ａｎａｌｙｓｉｓ）の結果に基づき選択される、マシーンアクセス可能な記憶媒体。
10. 前記選択された閾値は、前記更新フラグのチェック前に実行される最大ロード数を特定する、請求項９記載の記憶媒体。
11. 前記命令はさらに、前記マシーンにアプリケーションプロファイラにより前記閾値を決定させる、請求項１０記載の記憶媒体。
12. 前記閾値は、最適化前の前記最適化されたアプリケーションにおけるロード数及びストア数と、許容可能な最大エラーレートとの関数である、請求項１１記載の記憶媒体。
13. アプリケーション命令は、メモリパフォーマンスを向上させるため、更新されていないキャッシュメモリからの古いデータの限定的な抽出を許可するための許容可能なエラーレートを許容するため、遅延に耐性のあるグローバルデータのキャッシュコヒーランスを緩和するようコンパイラにより最適化される、請求項１記載のシステム。
14. 前記閾値は、実行期間中にアプリケーションコードにアクセス可能なメモリ、システムレジスタ又は他の位置の何れか１つにある、請求項１記載のシステム。
15. マルチプロセッサ、マルチコア又はマルチプロセッサ・マルチコアプラットフォームの１つを含む、請求項１記載のシステム。

Images