特許 5911985 ローカル物理メモリとリモート物理メモリとの間で共有されるバーチャルメモリのためのハードウェアサポートの提供

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5911985

(24)【登録日】2016年4月8日

(45)【発行日】2016年4月27日

(54)【発明の名称】ローカル物理メモリとリモート物理メモリとの間で共有されるバーチャルメモリのためのハードウェアサポートの提供

(51)【国際特許分類】

   G06F 12/10 20160101AFI20160414BHJP

   G06F 12/08 20160101ALI20160414BHJP

   G06F 12/06 20060101ALI20160414BHJP

【ＦＩ】

   G06F12/10 501Z

   G06F12/08 551C

   G06F12/08 507Z

   G06F12/06 530A

   G06F12/06 515L

【請求項の数】22

【全頁数】19

(21)【出願番号】特願2015-42361(P2015-42361)

(22)【出願日】2015年3月4日

(62)【分割の表示】特願2013-195581(P2013-195581)の分割

【原出願日】2010年9月14日

(65)【公開番号】特開2015-135696(P2015-135696A)

(43)【公開日】2015年7月27日

【審査請求日】2015年3月4日

(31)【優先権主張番号】12/562,477

(32)【優先日】2009年9月18日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】593096712

【氏名又は名称】インテル コーポレイション

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】ゴーサム エヌ． チャイニャ

(72)【発明者】

【氏名】ホーン ワーン

(72)【発明者】

【氏名】ディーパク エー． マサイカッティ

(72)【発明者】

【氏名】ジェイミソン ディー． コリンズ

(72)【発明者】

【氏名】イーサン シューフマン

(72)【発明者】

【氏名】ジェイムズ ピー． ヘルド

(72)【発明者】

【氏名】アジャイ ヴィー． バット

(72)【発明者】

【氏名】プラシャント セティ

(72)【発明者】

【氏名】スティーヴン エフ． ウォーリー

【審査官】 後藤 彰

(56)【参考文献】

【文献】 特開２００３−３１６６４６（ＪＰ，Ａ）

【文献】 特開２００３−３３７７１４（ＪＰ，Ａ）

【文献】 特表平１０−５０３３１０（ＪＰ，Ａ）

【文献】 特開２００７−２５７６３７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／０６

Ｇ０６Ｆ １２／０８

Ｇ０６Ｆ １２／１０

(57)【特許請求の範囲】

【請求項1】

バーチャルアドレスを含むメモリアクセスリクエストを受信するステップと、
プロセッサの変換ルックアサイドバッファ（ＴＬＢ）に格納される前記バーチャルアドレスに対応するエントリを解析し、前記バーチャルアドレスに対応する物理アドレス（ＰＡ）が前記プロセッサに関連するローカルメモリ、又は前記ＰＡが前記ローカルメモリ若しくは１以上のリモートメモリの１つに存在するか示すための前記ＴＬＢのエントリのローカル属性に基づき非コヒーラントリンクを介し前記プロセッサに接続されるアクセラレータに関連するリモートメモリに存在するか判断するステップであって、前記ローカルメモリと前記リモートメモリとは一緒になって共有バーチャルメモリスペースを構成する、判断するステップと、
前記ＰＡが前記リモートメモリに存在する場合、マイクロコードハンドラにより処理されるべきフォルト状態により前記メモリアクセスリクエストをタグ付けし、前記メモリアクセスリクエストを実行するため、前記非コヒーラントリンクを介しトンネルされる前記リモートメモリにリバースプロキシ実行リクエストを送信するステップと、
を有する方法。

【請求項2】

前記リモートメモリが関連付けされるアクセラレータを示す前記ＴＬＢのエントリの識別子フィールドを利用して、前記ＰＡが配置されるアクセラレータと関連付けされる複数のリモートメモリの何れかを決定するステップを更に有する、請求項１記載の方法。

【請求項3】

前記プロセッサによる前記リモートメモリのＰＡへのアクセスの回数を示す前記ＴＬＢのエントリのカウンタを解析するステップを更に有する、請求項２記載の方法。

【請求項4】

前記プロセッサによる前記リモートメモリのＰＡへのアクセスの回数を示す前記ＴＬＢのエントリのカウンタが閾値に達すると、前記プロセッサ上で実行されるアプリケーションの関与なく、前記リモートメモリのＰＡから前記ローカルメモリに情報を移動するステップを更に有する、請求項１記載の方法。

【請求項5】

前記ローカルメモリに関連する第１の物理アドレス範囲と前記リモートメモリに関連する第２の物理アドレス範囲とを示すため、前記ローカルメモリと前記リモートメモリとを含むシステムのメモリコンフィギュレーションを設定するステップを更に有する、請求項１記載の方法。

【請求項6】

前記メモリアクセスリクエストの変換を取得するため、ページウォーク上で前記メモリコンフィギュレーションにアクセスし、前記ＰＡが前記第１の物理アドレス範囲内にあるとき、前記ＰＡが前記ローカルメモリにあることを示すための第１の値を有する位置インジケータと前記変換とを含むエントリを前記ＴＬＢに格納するステップを更に有する、請求項５記載の方法。

【請求項7】

第１のメモリマネージメントユニット（ＭＭＵ）を含む第１のコアを有するプロセッサであって、
前記第１のＭＭＵは、バーチャルアドレスから物理アドレスへの変換を格納するための複数のエントリを有し、各エントリは、対応するエントリのメモリ位置が当該プロセッサに接続されるローカルメモリ、又は非コヒーラントインターコネクトを介し当該プロセッサに接続されるアクセラレータに接続されるリモートメモリに存在するか示すための第１のインジケータを格納するための位置フィールドと、前記リモートメモリに関連するアクセラレータの識別子を格納するための識別子フィールドとを有し、前記プロセッサは、フォルト状態により前記リモートメモリにおけるメモリ位置に対するメモリリクエストをタグ付けし、前記フォルト状態を処理するためのハンドラを実行し、前記リモートメモリにおける前記メモリ位置に対するメモリリクエストを、前記非コヒーラントインターコネクトを介した通信のためのダイレクトメモリアクセス（ＤＭＡ）に変換するプロセッサ。

【請求項8】

前記第１のＭＭＵの各エントリは、当該プロセッサによる前記リモートメモリのメモリ位置へのアクセスの回数のカウントを格納するためのカウンタを更に有する、請求項７記載のプロセッサ。

【請求項9】

前記ローカルメモリはシステムメモリであり、前記リモートメモリは前記アクセラレータのローカルメモリである、請求項７記載のプロセッサ。

【請求項10】

前記システムメモリと前記リモートメモリとは、単一のバーチャルアドレススペースを構成する、請求項９記載のプロセッサ。

【請求項11】

前記システムメモリと前記リモートメモリとは、単一のバーチャルアドレススペースを構成する、請求項９記載のプロセッサ。

【請求項12】

前記第１のＭＭＵのエントリは、前記メモリ位置が前記リモートメモリにあることを示し、当該プロセッサは、前記非コヒーラントインターコネクトのプロトコルを介し前記アクセラレータにメモリリクエストをトンネルする、請求項７記載のプロセッサ。

【請求項13】

前記アクセラレータは、第２のＭＭＵを有し、前記第２のＭＭＵ上のページフォルトに応答して、前記アクセラレータは、前記ページフォルトを処理するよう前記プロセッサにリクエストする、請求項７記載のプロセッサ。

【請求項14】

当該プロセッサは、前記第１のＭＭＵのエントリにおける情報を利用して、前記リモートメモリに存在するメモリ位置を直接アドレス指定する、請求項７記載のプロセッサ。

【請求項15】

当該プロセッサは、当該プロセッサ上で実行されるユーザレベルアプリケーションを利用することなく、前記第１のＭＭＵのエントリにおける情報を利用して前記アクセラレータのリモートメモリに格納されているデータにアクセスするためのリバースプロキシ実行リクエストを前記アクセラレータの発信する、請求項７記載のプロセッサ。

【請求項16】

第１のメモリマネージメントユニット（ＭＭＵ）を含む第１のコアを有するプロセッサであって、前記第１のＭＭＵは、バーチャルアドレスから物理アドレスへの変換を格納するための複数のエントリを有し、各エントリは、対応するエントリのメモリ位置がシステムメモリ、又はアクセラレータコンポーネントに関連する第２のメモリに存在するか示すためのインジケータを格納するための位置フィールドと、前記プロセッサによる第２のメモリのメモリ位置へのアクセスの回数のカウントを格納するためのカウンタとを有し、前記プロセッサ上で実行されるアプリケーションから独立して、前記プロセッサは、前記カウンタが閾値に達すると、前記メモリ位置に格納されているデータを前記第２のメモリに存在するメモリ位置から前記システムメモリに存在するメモリ位置に移動し、前記カウンタが前記閾値に達すると生じる例外に応答して、前記データの移動は前記プロセッサ上で実行されるアプリケーションにトランスペアレントである、プロセッサと、
リンクを介し前記プロセッサに接続されるアクセラレータコンポーネントであって、第２のプロセッサと第２のＭＭＵとを有するアクセラレータコンポーネントと、
前記プロセッサに接続されるシステムメモリであって、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）を有するシステムメモリと、
を有するシステム。

【請求項17】

前記プロセッサは、前記第１のＭＭＵのエントリにおける情報を利用して前記第２のメモリに存在するメモリ位置を直接アドレス指定する、請求項１６記載のシステム。

【請求項18】

前記システムメモリと前記第２のメモリとは、単一のバーチャルアドレススペースを構成する、請求項１６記載のシステム。

【請求項19】

前記プロセッサは、前記カウンタが前記閾値に達すると行われるインタラプトに応答して、前記プロセッサ上で実行されるアプリケーションの関与なく、前記第２のメモリに存在するメモリ位置から前記システムメモリに存在するメモリ位置にデータを移動する、請求項１６記載のシステム。

【請求項20】

前記プロセッサと前記アクセラレータコンポーネントとは、単一の半導体ダイから構成される、請求項１６記載のシステム。

【請求項21】

前記第２のメモリは、前記システムメモリのパーティションされた部分である、請求項２０記載のシステム。

【請求項22】

命令フェッチユニット、命令復号化ユニット及び第１のメモリマネージメントユニット（ＭＭＵ）を有する第１のコアであって、前記第１のＭＭＵは、バーチャルアドレスから物理アドレスへの変換を格納する複数のエントリを有し、各エントリは、前記第１のコアによるアクセスの回数のカウントを、前記プロセッサに接続される第２のプロセッサに関連する第２のメモリのメモリ位置に格納するためのカウンタを有し、エントリの前記カウンタが閾値に達すると、前記プロセッサは、前記エントリに関連するメモリ位置に格納されているデータを前記第２のメモリのメモリ位置から前記プロセッサに接続されるシステムメモリのメモリ位置に移動し、前記第１のコアは更に第１のキャッシュメモリと少なくとも１つの実行ユニットとを有する、第１のコアと、
インターコネクトと、
前記インターコネクトを介し前記第１のコアに接続され、第２のＭＭＵを有するアクセラレータであって、前記第２のＭＭＵはバーチャルアドレスから物理アドレスへの変換を格納する複数のエントリを有し、前記第１のＭＭＵの各エントリは、対応するエントリのメモリ位置が前記プロセッサに接続される第１のメモリ又は前記アクセラレータに接続される第２のメモリに存在するか示すための第１のインジケータを格納するための位置フィールドを有し、前記プロセッサは、前記第２のメモリにおけるメモリ位置に対するメモリリクエストを前記第２のメモリとの通信のためのダイレクトメモリアクセス（ＤＭＡ）に変換するためのハンドラを実行する、アクセラレータと、
前記第１のコアと前記アクセラレータとに接続される共有キャッシュメモリと、
前記共有キャッシュメモリに接続されるメモリコントローラと、
を有するプロセッサ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ローカル物理メモリとリモート物理メモリとの間で共有されるバーチャルメモリのためのハードウェアサポートの提供に関する。

【背景技術】

【0002】

プロセッサベースシステムが進歩するに従って、ＰＣＩ Ｅｘｐｒｅｓｓ^ＴＭ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｂａｓｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｖｅｒｓｉｏｎ ２．０（２００７年１月１７日に公開された）（以降、ＰＣＩｅ^ＴＭ仕様書）又は他の同様のプロトコルに基づくリンクに従って、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ（ＰＣＩｅ^ＴＭ）インターコネクトなどの高速周辺相互接続を介しシステムに接続されるプログラマブルアクセラレータの利用性は、システムインテグレータがより高い計算パワーをシステムに与えることを可能にする。しかしながら、メインプロセッサ（マルチコア中央処理ユニット（ＣＰＵ）など）とアクセラレータとの間に計算を手作業により分割するため、アプリケーションに大きな変更をすることなくアプリケーションがさらなる計算パワーを透過的又はトランスペアレント（ｔｒａｎｓｐａｒｅｎｔ）に利用し、データの前方及び後方への移動を管理することが可能になることを保障することは困難である。従来、オペレーティングシステム（ＯＳ）により管理されるメインシステムメモリのみが、アプリケーションの利用のために割り当てられた。周辺相互接続を介し接続されるアクセラレータにローカルな物理メモリは、別々に管理される。特に、アクセラレータ上のローカルメモリは、メインプロセッサ上で実行されるＯＳにより認識可能なシステムメモリの一部としては見られない。その代わりに、デバイスドライバソフトウェアが、ローカルメモリとリモートメモリとの間のデータ移動を明示的に管理している。

【0003】

プロセッサによりアクセスされる物理メモリは、連続的で大規模なバーチャルアドレススペースの錯覚をもたらすため、物理メモリへのアクセスを仮想化するオペレーティングシステムにより管理される。プロセッサはソフトウェアがバーチャルページを物理ページにマップするためのマッピングテーブルを設定することを可能にするため、ＯＳは、バーチャルメモリ管理の基礎となるプロセッササポートを利用する。プロセッサは、メモリアクセスが行われる必要がある度に、マッピングテーブルに照会することによってバーチャルメモリアドレス変換をサポートする。頻繁にアクセスされる変換は、プロセッサがこの処理をスピードアップすることによってキャッシュ可能である。ページテーブルとも通常呼ばれるこれらのマッピングテーブルはまた、所与のバーチャルページへのアクセスを制御するリード／ライト及びユーザ／スーパーバイザ特権ビットなどの属性ビットを含む。ＯＳがマザーボード上で利用可能な物理メモリ（システムメモリ）を管理している間、それはアクセラレータにローカルで利用可能なメモリを管理又は割り当てない。従って、現在の課題は、プログラマによって見えるような共有メモリモデルを構成し、異なるメモリの間でページをフォルト及び移動させるためにメモリプロテクション機構に依存するものである。

【発明の概要】

【発明が解決しようとする課題】

【0004】

本発明の課題は、ローカル物理メモリとリモート物理メモリとの間で共有されるバーチャルメモリのためのハードウェアサポートを提供することである。

【課題を解決するための手段】

【0005】

上記課題を解決するため、本発明の一態様は、バーチャルアドレスを含むメモリアクセスリクエストを受信するステップと、前記バーチャルアドレスに対応する物理アドレス（ＰＡ）がプロセッサに付属されるローカルメモリ又は非コヒーラントリンクを介し前記プロセッサに接続されるアクセラレータに付属するリモートメモリに存在するか判断するため、前記プロセッサの変換ルックアサイドバッファ（ＴＬＢ）に格納される前記バーチャルアドレスに対応するエントリを解析するステップと、前記ＰＡが前記リモートメモリに存在する場合、前記メモリアクセスリクエストを実行するため、リバースプロキシ実行リクエストを前記リモートメモリに送信するステップとを有する方法であって、前記ローカルメモリと前記リモートメモリとは、一緒になって共有バーチャルメモリスペースを構成する方法に関する。

【発明の効果】

【0006】

本発明によると、ローカル物理メモリとリモート物理メモリとの間で共有されるバーチャルメモリのためのハードウェアサポートを提供することができる。

【図面の簡単な説明】

【0007】

【図1】図１は、本発明の一実施例によるシステムのブロック図である。

【図2】図２は、本発明の一実施例によるリバースプロキシ実行方法のフロー図である。

【図3】図３は、本発明の一実施例によるリバースプロキシ実行処理を示すブロック図である。

【図4】図４は、本発明の一実施例によるプロキシ実行方法のフロー図である。

【図5】図５は、本発明の一実施例によるプロキシ実行処理を示すブロック図である。

【図6】図６は、本発明の一実施例によるページテーブルの一例となるエントリである。

【図7】図７は、本発明の一実施例によるプロセッサのブロック図である。

【図8】図８は、本発明の一実施例によるオンチップアクセラレータを有するシステムのブロック図である。

【発明を実施するための形態】

【0008】

以下、図面に基づいて本発明の実施の形態を説明する。

【0009】

各実施例は、プロセッサ（ソケット上の中央処理ユニット（ＣＰＵ）など）がアクセラレータ上のメモリにアクセスし、特別なロード／ストアトランザクションを利用してメモリをアドレッシングすることによって、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ（ＰＣＩｅ^ＴＭ）などのインタフェースによりシステムに相互接続されるアクセラレータによる完全に共有されたバーチャルアドレススペースを構成及び管理することを可能にする。リモートメモリをアドレッシングすることが可能であることは、アプリケーションソフトウェアにより見える有効計算キャパシティを増加させることを直接可能にし、データを前方及び後方に移動させるのにプログラマの明示的な関与なくアプリケーションがデータをシームレスに共有することを可能にする。このようにして、メモリは、メモリプロテクションを用いる必要なく、またフォルトハンドラから完結されるべきメモリアクセスをリダイレクトするためにバーチャルアドレスアクセス上でフォルトすることなく、アドレッシング可能である。また、既存の共有メモリマルチコア処理は、ソケット上にはないが、周辺のコヒーラントでないリンクを介し接続されるアクセラレータを含むよう拡張可能である。

【0010】

他方、クラスタベースシステムなどの典型的なシステムは、プログラマにより見えるような部分的な共有メモリモデルを構成し、ＣＰＵと周辺デバイスとの間でページをフォルト及び移動するためにメモリプロテクション機構に依存する。また、クラスタベースシステムでは、各ノードはオペレーティングシステム（ＯＳ）スタックの別のコピーを実行し、その先頭においてアプリケーションが実行される。アドレススペースの一部しか共有されず、プログラマはデータのどの部分が共有アドレススペースに配置されるか共有エリアから割り当てるか、又は明示的に指定するため、システムのこの特徴はプログラマに明らかにされる。この実行環境は、単一共有メモリマルチコアシステムに類似する完全共有メモリ実行環境とは異なる。

【0011】

各種実施例では、ソケット上のプロセッサは、アクセラレータにローカルなリモートメモリをアドレッシング可能であり、このことは、プロセッサがリモートメモリアドレスを透過的に用いて共有データにアクセスすることを可能にする。これを実現するため、バーチャルメモリマネージメントシステムが、特別なロード／ストアトランザクションがリモート共有データをアドレッシングするため発行可能となるようにエンハンスされ、さらに明示的なプログラマの関与を必要とすることなくシステムがメモリページをより頻繁にアクセスされる場合にはより近くに移動することを可能にするため、アーキテクチャの拡張が提供される。さらに、メモリマネージメントの拡張は、プログラマがアドレススペースの何れの部分が共有される必要があるか明示的に指定する必要なくアプリケーションコードを直接実行し、又はプログラマが共通の共有データエリアを管理することを可能にする。

【0012】

また、キャッシュコヒーラントなＣＰＵソケット上のコアと周辺相互接続を介しシステムに相互接続されるアクセラレータ（マルチコアＣＰＵを含む）との間で共有されるバーチャルアドレススペースが構成及び管理可能である。このため、相互接続の両サイドのＣＰＵ／アクセラレータは、キャッシュコヒーラントであってもよいし又はなくてもよい相互接続を介しアクセラレータにローカルなメモリ又はシステムメモリに物理的に配置される共有バーチャルページにアクセス可能となる。

【0013】

従って、アクセラレータのローカルメモリが相互接続を介し、コヒーラントなファブリック（フロントサイドバス（ＦＳＢ）又はクイックパスインターコネクト（ＱＰＩ）など）を介しＣＰＵにより直接的にはアクセス可能でなくても、アクセラレータ上のローカルな物理メモリは、ＣＰＵとさらにＯＳ及びアプリケーションへの追加的なシステムメモリとして動作可能である。

【0014】

各実施例は、多数の異なるシステムタイプにより実現可能である。図１を参照して、本発明の一実施例によるシステムのブロック図が示される。図１に示されるように、システム１００は、例えば、ＰＣＩｅ^ＴＭリンクであってもよいコヒーラントでないインターコネクト１４０を介しアクセラレータカード１５０に接続されるホストパーソナルコンピュータ（ＰＣ）プラットフォーム１１０を有する一例となるコンピュータシステムである。図示されるように、ホストプラットフォーム１１０は、ＣＰＵ１２０と、一部の実施例ではＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）であるシステムメモリ１３０とを有する。図１では簡単化のため最小限の構成要素しか示されていないが、所与のプラットフォームは、入出力ハブ、チップセットコンポーネント、周辺デバイス、大容量記憶装置、入出力デバイスなどを含む他の多数の典型的な構成要素を含むものであってもよいことは理解されるであろう。

【0015】

図１に示されるように、ＣＰＵ１２０は、メモリマネージメントユニット（ＭＭＵ）１２５を有する。ＭＭＵ１２５は、バーチャルアドレスと物理アドレスとのマッピングを可能にし、一部の実施例では、１以上の変換ルックアサイドバッファ（ＴＬＢ）を有する。後述されるように、本発明の一実施例によるＭＭＵへの各種アーキテクチャの拡張は、プラットフォーム１１０とアクセラレータカード１５０に付属するメモリの間の共有バーチャルメモリの構成及び利用を可能にする。

【0016】

図１を参照するに、アクセラレータカード１５０は、グラフィックス処理ユニット、ＣＰＵ又は他の何れか同様のデバイスなどの何れかのタイプのアクセラレータであってもよいインテレクチャルプロパティ（ＩＰ）ブロック１６０を有する。図示されるように、このＩＰブロック自体がＭＭＵ１６５を有する。プラットフォーム１１０との通信を可能にするため、ブリッジ１５５が、インターコネクト１４０のためのプロトコルに従って行われる通信を、システムオンチップ（ＳｏＣ）ファブリック１７０上で使用されるものと整合するプロトコルに変換するため存在し、ＳｏＣファブリック１７０は次にＩＰブロック１６０をＤＲＡＭであってもよいローカルメモリに接続する。図１の実施例では特定の実現形態により示されているが、本発明の範囲はこれに限定されるものでない。

【0017】

各実施例は、オンボード（マザーボードなど）システムメモリの外部の物理メモリアクセスをＣＰＵが特定可能であることをエンハンスするリバースプロキシ実行（ＲＰＥ）を実現する。このとき、このような位置へのアクセスは、周辺ファブリックを介しアクセラレータにトンネルされるアクセスクラスに変換される。さらに、アクセラレータは、それのローカル物理メモリからのアクセスに利用される。ＲＰＥとプロキシ実行（ＣＰＵがアクセラレータのリクエストの下でメモリアクセスの完了を支援する）とを一緒に利用して、（コヒーラント又は非コヒーラントな）ファブリックを介しマルチソケットＣＰＵに接続される独立したＭＭＵを有する任意のアクセラレータは、システムメモリとアクセラレータローカルメモリとの双方を含む物理メモリのための共有バーチャルアドレススペースを構築可能である。ＲＰＥとプロキシ実行とを利用して、一実施例は、従来のシンメトリックなマルチプロセッシング（ＳＭＰ）のために構築された同一のマルチスレッド共有バーチャルメモリベースプログラムが、周辺Ｉ／Ｏファブリック上の複数のストップ又は複数のＣＰＵソケット上にある各ＣＰＵにスレッドを分散させることを可能にする。

【0018】

アーキテクチャ機構と共に、各実施例はまた、周辺インターコネクトを介しソケットとアクセラレータ（又はＣＰＵ）上のコアの間の制御及びデータ転送がそれぞれが異なる最適化オプションを備えた完全にＯＳアンアウェアなものからＯＳアウェアなものまでの異なる抽象化レベルにおいて透過的に動作することを可能にするファームウェア及びシステムソフトウェアの拡張を含む。

【0019】

データは、アクセラレータサイドと共にＣＰＵサイドからの共有データに対するアクセスパターンに基づく要求ベースにより共有可能である。バーチャルアドレスにより動作し、アドレス変換をサポート可能なアクセラレータは、アクセラレータがアプリケーションプログラムの一部を実行する際にコード又はデータを参照するときに同一のバーチャルアドレスが利用可能であるため、手つかずのままのデータ及びコードを参照して同一のコードを透過的に実行可能である。コード又はデータを含む物理ページは、アクセラレータにローカルに配置可能であるか、又はシステムメモリからフェッチ可能である。バーチャルページは、アプリケーションがアクセラレータ上での計算を設定するためのデータ移動を管理することが不要であるため、アプリケーションソフトウェアスタックの明示的な関与なくアクセス頻度に基づき、リモート位置からローカル位置に移動可能である。

【0020】

ドライバソフトウェアには、しばしばメインシステムメモリとアクセラレータにローカルなリモートメモリとの間のＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）転送を利用して、データを大量に明示的に移動するジョブが課せられる。従来のドライバモデルでは、ＣＰＵ上で実行されるアプリケーションプログラムとアクセラレータを管理するドライバプログラムとは、典型的には２つの異なるバーチャルアドレススペースにある。このため、アプリケーションとドライバとの間のデータ通信と、システムメモリとアクセラレータローカルメモリとの間のデータ転送とのために、かなりのオーバヘッドが通常生じる。さらに、このデータ転送は、典型的には、プログラマにより記述されるアプリケーションコードにより実現される。例えば、プログラマは、ベンダ固有のアプリケーションプログラミングインタフェース（ＡＰＩ）セットを利用して、システムメモリからアクセラレータメモリにデータを手動により移動することが要求される。ＤＭＡ処理の明示的な管理を必要とすることのない、本発明の一実施例によるＣＰＵとアクセラレータコアとの間の共有バーチャルアドレススペースの構成は、データ共有化をかなり簡単化する。これは、アプリケーションコードとデータ全体が、例えば、プログラマによるＤＭＡ処理の明示的な編成などによりアプリケーションプログラムを変更することによってデータを明示的に移動させる必要なく、共通の共有バーチャルアドレススペースに配置可能であるためである。従って、データ転送は依然としてＤＭＡにより可能であるが、それらはプログラマにより制御されない。すなわち、プロセッサは、データアクセスを可能にするため基礎となるファブリックを設定及び管理するためのプログラマによる明示的なプログラミングなく、ユーザレベルアプリケーションの実行中にリモートメモリに存在するデータに直接アクセスする。

【0021】

ＣＰＵとアクセラレータとの間の共有アドレススペースを構成するため、メモリマネージメントユニットは、共有バーチャルアドレススペースへのロード／ストアアクセスが、仮想アドレスから物理アドレスへの変換に用いられるページテーブルのコンテンツに基づきリモートメモリに送られることを可能にする。

【0022】

システムソフトウェアサポートは、ランタイムシステムがバーチャルページの位置を透過的かつ動的に移動することを可能にする。これにより、ＣＰＵとアクセラレータとの間の共通の共有バーチャルアドレススペースが構成可能となり、プログラムのランタイムワーキングセットロカリティ動作が、アクセスが頻繁でない場合にはバーチャルページをリモートに配置し、又は頻繁にアクセスされるページに対してはローカルにそれらを配置するのに利用される。

【0023】

各種実施例では、バーチャルメモリサポートを拡張するための異なる機構が提供される。１つの実現形態は、既存のレガシーページングシステム設計に対するＯＳの変更を含まないが、他の実現形態は、ページテーブルエントリにより多くの情報を追加可能である。これらの機構は、リバースプロキシ実行、すなわち、ＣＰＵがシステムメモリ上でなく周辺ファブリックのアクセラレータにローカルなリモート物理メモリにマップされるバーチャルアドレスアクセスを特定及び提供する機能をサポートするための同様のアーキテクチャ機構を伴う。

【0024】

ＲＰＥをサポートするため、ＣＰＵは、与えられたバーチャルアドレスがシステムメモリ又は周辺ファブリックのリモートメモリにマップされるか特定する。物理アドレスがシステムメモリにマップされた場合、当該アクセスは通常のメモリアクセスによりローカルに処理され、そうでない場合、ＲＰＥが当該アクセスを処理するよう指示される。一実施例では、ＲＰＥは、専用のマイクロコードフローを用いて実現されてもよい。ＲＰＥは、マイクロコードハンドラにより処理される特別なフォルト状態によりアクセス（ロード／ストア（ＬＤ／ＳＴ）など）をタグ付けすることによって開始される。複数の変形が可能であるが、ハンドラはアクセスを周辺ファブリックのＲＥＡＤ／ＷＲＩＴＥ／ＤＭＡトランザクションに変換する。説明の簡単化のため、周辺ファブリックはＰＣＩｅ^ＴＭインターコネクトであり、リモート物理メモリへの個別の各アクセスはキャッシュ不可なアクセスに変換され、さらにＰＣＩｅ^ＴＭファブリック上のリクエスト／データをトンネルするため、ＰＣＩｅ^ＴＭデータトランザクションに変換されると仮定する。このトランザクションは、オリジナルのバーチャルアドレス又は物理アドレスをカプセル化可能である。一部の実施例では、アクセスを実行するＣＰＵスレッドは、リモートアクセスの保留中の完了をストールしてもよい（又は他のスレッドにスイッチしてもよい）。アクセラレータがＣＰＵからアクセスリクエストを通知するＰＣＩｅ^ＴＭトランザクションを受信すると、アクセラレータのシーケンサは当該リクエストを特別なインタラプトイベントとして処理する。シーケンサは、当該リクエストからアクセスアドレスとアクセスタイプとを抽出する。アクセスアドレスがバーチャルアドレスである場合、シーケンサは、物理アドレスを取得するため、ローカルＭＭＵを介しトランザクションをローカルに実行する。物理アドレスを利用して、アクセラレータのシーケンサは、ストアをコミットするか（ライトトランザクションの場合）、又はロードのためのデータを取得する（リードトランザクションの場合）。シーケンサは、リプライ（ロードの場合など）をＰＣＩｅ^ＴＭトランザクションにカプセル化し、ホストルート（すなわち、ＣＰＵ）に送り返す。ＣＰＵコアは、ＰＣＩｅ^ＴＭトランザクションと完了したアクセスの状態とを受信し、以降の処理を再開する。これにより、リモートアクセスのアクセス状態に基づくアクセスフォルトが生じうる。

【0025】

図２を参照するに、本発明の一実施例によるリバースプロキシ実行のためのフロー図が示される。図２に示されるように、アクセラレータのローカルメモリ、すなわち、ＣＰＵに関するリモートメモリ上にあるデータにアクセスするため、方法２００が利用される。図２に示されるように、方法２００は、メモリアクセスリクエストを受信することによって開始される（ブロック２１０）。このリクエストはホストＣＰＵにおいて受信され、さらにエントリがＴＬＢにあるバーチャルアドレスのためのものであるか判断するため、ＴＬＢなどのＭＭＵに転送される（ダイアモンド２２０）。エントリがＴＬＢにあるバーチャルアドレスのためのものでない場合、ページミスハンドラが、エントリを取得し、ＴＬＢに格納するため実行される（ブロック２２５）。

【0026】

エントリがＴＬＢにあるとき、それは対応する物理アドレスの位置を決定するため解析される（ブロック２３０）。例えば、後述されるように、各ＴＬＢエントリは、対応するページがローカルメモリ（すなわち、システムメモリ）又はリモートメモリにあるか示すための情報を含むものであってもよい。物理アドレスがシステムメモリにある場合（ダイアモンド２４０）、制御はブロック２４５に移行し、メモリアクセスリクエストがシステムメモリに対して実行され、リクエストされたデータがレスポンスとしてリクエスト元に提供される（ブロック２５０）。

【0027】

ダイヤモンド２４０において、物理アドレスがシステムメモリにないと判断された場合、制御はブロック２６０に移行する。ブロック２６０において、データを含むメモリアクセスリクエストをリモートメモリ（アクセラレータのローカルメモリなど）に送信するため、リバースプロキシ実行リクエストが用意される。各種実施例では、このリクエストは、特別なロード／ストアリクエストなどとして非コヒーラントインターコネクトにおいてトンネリングされる。このリバースプロキシ実行リクエストがアクセラレータ上で処理された後、制御はブロック２７０に移行し、リバースプロキシ実行リクエストの結果が受信される。すなわち、ブロック２５０に関連して上述されたように、リクエストされたデータが受信され、レスポンスがリクエスト元に提供可能である。図２の実施例では特定の実現形態が示されたが、本発明の範囲はこれに限定されるものでない。

【0028】

図３を参照して、本発明の一実施例によるリバースプロキシ実行のための処理を示すブロック図が示される。図３に示されるように、ＣＰＵ１２０からＭＭＵ１２５へのバーチャルアドレス（Ｖ．Ａ）Ｘにアクセスする（１）リクエストが失敗すると（例えば、ルックアップが、当該ページはアクセラレータカードのローカルメモリにあることを示すなど）、リバースプロキシ実行リクエストが用意され、アクセラレータカード１５０に送信される（２）。次に、アクセラレータ１６０は、メモリアクセスリクエストをＭＭＵ１６５に送信する（３）ため当該リクエストを処理し、次にＭＭＵ１６５はローカルメモリ１８０のリクエストされたページにアクセスする（４）。これにより、リクエストされたデータはＣＰＵ１２０に送り返すことができる（５）。アクセラレータからのデータはＤＭＡを介しホストＣＰＵに送信可能であるか、又は見せかけのＬＤ／ＳＴ実現形態内のホストの下ですべてをポーリング可能である（マイクロコードフローなどにおいて）ことに留意されたい。すなわち、ＣＰＵがリモートメモリ位置へのアクセスを送出すると、ＣＰＵは、ＤＭＡインタラプトを待機するか又はアクセラレータからの“リターン”データを取得するためアクティブなポーリングを実行する見せかけのＬＤ／ＳＴを実行するためのマイクロコードルーチンへのアクセスに移る。（Ｖ．Ａ）Ｘへのメモリアクセスの完了は、バーチャルアドレスＸにおいて特定されるメモリ位置にアクセスしたアプリケーションプログラムに透過な方法により実行される。

【0029】

全体的に、ＲＰＥ処理は非一様メモリアーキテクチャ（ＮＵＭＡ）システムにおける長い遅延メモリアクセス処理と同様に機能する。基礎となるトンネリング機構は、ファブリックの性質に応じて変更される。ＰＣＩｅ^ＴＭファブリックの場合、ルート（システム）とチャイルド（アクセラレータ）コンプレックスとの間の非対称性によって、ＣＰＵは通常はアクセラレータのローカルメモリの何れにもアクセスできないが、アクセラレータがシステムメモリの範囲にアクセス可能な場合、ＲＰＥ実行機構の各種最適化は、システムメモリ又はアクセラレータのローカルメモリの一部をプライベートメモリとして利用することによって実現される。一実施例では、システムメモリの一部はリモートアクセラレータのローカルメモリのキャッシュとして確保可能である。あるいは、プライベートメモリ領域は、リモートアクセスされるバーチャルページを保持するためのバッファとして機能するよう割当て可能である。例えば、リモートページにマップされるバーチャルアドレスＸへのアクセスは、ページ全体がリモートメモリアクセスを減少させるため、以降のアクセスのために利用可能なローカルバッファに一時的に読み込まれる。

【0030】

一実施例では、プロキシ実行機構は、アクセラレータのシーケンサ上で起こるページフォルト状況を処理するのに利用され、これは、当該フォルトが処理のためＣＰＵに送信可能であることを意味する。これは、アクセラレータのシーケンサ上のＭＭＵがＣＰＵのＭＭＵとコヒーラントであり、すべてのポイントがＯＳの同一のページテーブルになることを意味する。ＣＰＵ又はアクセラレータ上での処理により生じるか否かにかかわらず、バーチャルページへのページフォルトは、ＣＰＵに従来のページ処理機構を利用して当該ページをメモリに配置させる。フォルトがアクセラレータのシーケンサ上のアクセスから生じたものである場合、ＣＰＵは、新たなページをリモートアクセラレータのローカル物理メモリにインストールする。そうでない場合、ページはシステムメモリに配置可能である。リモートアクセラレータのローカルメモリにマップされたバーチャルアドレスへのＣＰＵ上での非フォルトアクセスは、アクセラレータの物理ページにマップすることを保障し、プロキシ実行の完了を保障する。

【0031】

図４を参照して、本発明の一実施例によるプロキシ実行方法のフロー図が示される。図４に示されるように、アクセラレータにより所望されるデータがそれのローカルメモリにないときにプロキシ実行を実行するため、方法３００が利用される。

【0032】

図４に示されるように、方法３００は、アクセラレータからメモリアクセスリクエストを受信することにより開始される（ブロック３１０）。その後、当該リクエストのバーチャルアドレスのエントリがアクセラレータのＴＬＢにあるか判断される（ダイアモンド３５０）。当該リクエストのバーチャルアドレスのエントリがアクセラレータのＴＬＢにある場合、アクセラレータのローカルメモリがこのバーチャルアドレスを用いてアクセスされ（ブロック３７０）、リクエスト元にレスポンスが提供される（ブロック３８０）。

【0033】

他方、エントリがＴＬＢにない場合、制御はブロック３３０に移行し、プロキシ実行リクエストがＣＰＵに送信される（ブロック３３０）。リクエストされた変換がＣＰＵのＭＭＵにないとすると、ページミスハンドラがエントリを取得するため実行される（ブロック３３５）。さらに、このバーチャルアドレスに対応するページが、システムメモリからアクセラレータのローカルメモリに移動される（ブロック３４０）。その後、再開メッセージがＣＰＵからアクセラレータに送信される（ブロック３５０）。エントリがＭＭＵにあるため、メモリアクセスリクエストが、リクエストされたデータを取得するためローカルメモリに対して実行される（ブロック３７０）。リクエストされたデータを含むレスポンスがリクエスト元に提供される（ブロック３８０）。

【0034】

図５を参照して、本発明の一実施例によるプロキシ実行処理を示すブロック図が示される。図５に示されるように、プロキシ実行ｈまアクセラレータがローカルＭＭＵ１６５にないバーチャルアドレス（Ｖ．Ａ）Ｘへのアクセスをリクエストしたときに行われる（１）。このページフォルトに対するプロキシ実行リクエスト（２）が、ＣＰＵ１２０に送信される。図５は、ＭＭＵ１６５がプロキシ実行リクエストをＣＰＵ１２０に直接送信する実現形態を示す。しかしながら、プロキシがページウォーキングコード（ＭＭＵがどのように管理されるかに応じてマイクロコード、ファームウェア又はソフトウェア）により実現されるとき、このコードはプロキシリクエストを送信可能である。ＣＰＵ１２０は、当該リクエストをローカルＭＭＵ１２５に送信し（３）、ＭＭＵ１２５はさらにリクエストされたバーチャルアドレスに対してシステムメモリ１３０のページにアクセスする（４）。図示されるように、リクエストがデータの読み込むに対するものであるとき、ページ全体がシステムメモリ１３０からローカルメモリ１８０に送信される（５）。一実施例では、データ転送は、データをシステムメモリ１３０の領域からローカルメモリ１８０の領域にコピーするようＤＭＡをプログラムするＣＰＵ１２０を介して行われる。あるいは、ＣＰＵ１２０は、上述されるマイクロコードを用いて実現されるなど、“見せかけの”各ロード／ストア命令シーケンスを実行することによってコピーを実行可能である。その後、ＣＰＵ１２０は、再開メッセージをアクセラレータ１６０に送信し（６）、アクセラレータ１６０はさらにＭＭＵ１６５へのアクセスをリトライする（７）。そして、現在の変換を検出し、対応するデータをローカルメモリ１８０から取得するためリクエストが送信される（８）。ローカルメモリ１８０のデータへのアクセスを可能にするため、ＭＭＵ１６５がアドレッシング可能とされることに留意されたい。ＣＰＵ１２０は、システムメモリ１３０上のページテーブルからＭＭＵ１６５への変換エントリを更新するため、“見せかけ”の各ＬＤ／ＳＴを直接実行する。あるいは、ＣＰＵ１２０は、アクセラレータサイドにローカルメモリ１８０へのデータ転送を介し変換を含むページテーブル又はその一部をコピーすることが可能であり、その後、ローカルに配置されたページテーブルをウォークするページウォーカを有するアクセラレータ１６０を再開する。

【0035】

ＣＰＵ上のバーチャルアドレスアクセスがローカル（システムメモリにおいて）又はリモート（アクセラレータのメモリにおいて）であるか区別するための情報は、システムメモリコンフィギュレーションに関する完全な知識を有するＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）から当該情報を獲得するＯＳから与えられる。ＲＰＥをサポートするため、ＢＩＯＳは、アクセラレータに関する通知されたメモリサイズを列挙する。この処理は、ＢＩＯＳによりブート時に実行されるＲＯＭ／ＲＡＭチップセレクトに類似している。その後、ＢＩＯＳは、システムメモリとアクセラレータローカルメモリとの和を報告し、ＯＳにメモリの何れの範囲がローカルシステムメモリであるか、またリモートであるかを通知する。

【0036】

各種実施例では、メモリパーティション記述子と呼ばれる、ＢＩＯＳのシステムレベル状態、すなわち、記述子アーキテクチャ状態セットが、このレンジ情報、例えば、最小ではシステムメモリのレンジ情報を記録する。これにより、この範囲外の物理アドレスは、リモートとして特定される。一実施例では、この情報はＢＩＯＳビルトインデータ構造に格納可能である。メモリ記述子はまた、ソフトウェアとマイクロコードとの双方にアクセス可能なマシーンに固有のレジスタにプライベート状態として格納される。このようなレンジ情報はまずＯＳのスタート前にＢＩＯＳにより確定され、これらの状態の使用はＯＳに従属しないことに留意されたい。すなわち、ＲＰＥ機構は、リモートメモリとローカルメモリとの区別を意識しないレガシーＯＳにより機能可能である。

【0037】

ＣＰＵにより処理される所与のＬＤ／ＳＴについて、各ＴＬＢ変換に物理アドレスとメモリパーティション記述子とを比較させ、それがローカルシステムメモリかリモートアクセスであるか決定させることは困難である。代わりに、このようなチェックはＭＭＵのクリティカルなパスから離れて実行可能であり、新たなＴＬＢエントリが充填されると、ページウォーク上でのみ実行される。一部の実施例では、各ＴＬＢエントリは、対応するエントリがリモート又はローカルシステムメモリにあるか示すための属性ビットを含むことが可能である。新たなＴＬＢエントリがインストールされると、ページウォーカは、メモリパーティション記述子に対してページテーブルエントリの物理アドレス範囲のレンジチェックを実行可能である。この機構は、ＯＳがローカルに又はリモートにマップされるページとを区別しない場合であっても機能することに留意されたい。

【0038】

一部の実施例では、ＯＳは、アクセラレータのローカルメモリを用いてアクセラレータが頻繁にアクセスするアプリケーションのコード及びデータの一部のみを保持することによって、アクセラレータのローカルメモリの利用の背後にあるポリシーを処理することができる。ＯＳがアウェアでない場合、ランタイムレイヤ又は他のエンティティなどのロカリティ原理は、システムメモリ又はアクセラレータローカルメモリにおいてアクセスがより頻繁に発生する場所に近いワーキングセットを移動するのに役立つ。

【0039】

さらに、上述されるように、ＯＳページテーブルフォーマットは、対応するページがローカルメモリ又はリモートメモリに格納されるか示すための属性ビットを有することが可能である。このビットは、ＯＳがバーチャルアドレスと物理アドレスとのマッピングを確定するとマークでき、各物理ページに対して、ＯＳは当該ページをローカル又はリモートとしてマークするため、メモリパーティション記述子によりチェックすることができる。このように、範囲のチェックはインストールされたＴＬＢエントリに対して実行される必要がない。アプリケーションがアクセラレータ上のメモリにアクセス可能にするため、ＣＰＵは属性ビットを解析し、これにより、それが所与のバーチャルアドレスへのロード／ストアをリモート物理メモリ位置に指定可能となる。さらに、属性ビットはまたリモートに実行されるアクセスの回数を追跡し、リモートアクセスの回数が特定の閾値を超える場合、ページが他の場所に移動可能となるように、ＯＳソフトウェアがリモートアクセスの回数に基づきポリシーを実現することを可能にする。

【0040】

ページをアクセス不可又は存在しないとしてマーク付けするなど、バーチャルページのプロテクションを実行し、結果としてのフォルトを処理することによって、リモートメモリアクセスを実現することが可能であるが、メモリアクセスが行われる毎にページフォルトハンドラが実行される必要があるため、アクセス遅延は増大する。その代わりに、本発明の一実施例を用いて、ＣＰＵは、リモートメモリ位置アドレスをバスコントローラに提供することが可能であり、バスコントローラは当該アクセスをアクセラレータのメモリ位置に誘導する。例えば、ＣＰＵは、ロード／ストアを完了させるためのソフトウェアからの支援なしにリモートメモリ位置にアクセスするため、バスコントローラにおいて規定された標準的なレジスタセットにアクセスすることによって、ロード／ストアを直接リダイレクトすることが可能である。このデータ転送はＤＭＡ（バルク転送）によるものであってもよいし、又はキャッシュライン粒度によるスカラー転送であってもよい。バーチャルページをリモートメモリ位置からローカルメモリ位置に（またその反対）透過的に移動させる機能は、ソフトウェア（アプリケーションなど）がデータの移動を明示的に管理することなくアクセラレータとデータを共有することを可能にする。アクセラレータがシステムに接続されず、又は非応答状態に入ると、アドレス変換ユニットは、ロード／ストアが失敗した理由を示すページフォルトを生成する。

【0041】

図６を参照して、本発明の一実施例によるページテーブルにおける一例となるエントリ４００が示される。図示されるように、各エントリは、メモリに格納されているページの第１アドレスを示すＰＢＡを格納するページベースアドレス（ＰＢＡ）を有する。さらに、各エントリは、当該ページを有するシステムにあるアクセラレータを参照するためのｎビットアクセラレータ識別子（ＩＤ）を格納するアクセラレータフィールド４２０と、対応するバーチャルページがローカルメモリ又はおそらく多数のリモートメモリの１つに格納されているかに関するｎビットインジケータなどを格納するローカル／リモートフィールド４３０と、リモートメモリになされるアクセスの回数をカウントするｍビットカウンタを格納するカウンタフィールド４４０と（カウンタは、ページがリモートメモリにある場合にのみアクティブとなるよう）、ページの異なる属性を示すための各種ビットを格納する属性フィールド４５０とを有する。

【0042】

一実施例では、アクセスカウンタの値がゼロになると、例外処理が引き起こされる。この例外処理は、ページ移動のためのバーチャルメモリ管理カーネルなどのＯＳソフトウェアが与えられたバーチャルページへのアクセス回数に基づき移動ポリシーを管理することを可能にする。すなわち、ソフトウェアは、バーチャルアドレススペースがＣＰＵ又はアクセラレータにより近くにある物理メモリページをマップすることが可能となるように、アプリケーションが処理するバーチャルアドレススペースを管理することができる。ＰＣＩｅ^ＴＭバスに接続されるアクセラレータについて、バスがコヒーラントでないとき、基礎となるランタイムソフトウェアは、ソフトウェアベースのコヒーレンス機構を実現してもよい。何れかの共有データ構造への競合するアクセスに対して、セマフォなどの同期制御は、生成スレッドがデータをコンシューマにハンドオフする準備ができるまでセマフォをリリースしないように利用可能である。生成スレッドがセマフォをリリースする前、それは、共有データに関するすべてのダーティキャッシュラインをメモリにフラッシュする必要がある。これは、アクセラレータ上のコンシューマスレッドがメモリから共有データへのアクセスを開始すると、ホストＣＰＵとアクセラレータとの間のファブリックがキャッシュコヒーレンシをサポートしなくても、データがコヒーラントであることを保障する。他方、アクセラレータが共有データの処理を終了すると、同様の同期及びフラッシュ機構が、メモリベースデータコヒーレンシを保障するのに利用可能である。ＣＰＵとアクセラレータとの間のファブリックがキャッシュコヒーラントである場合（例えば、ＰＣＩｅの以降の生成など）、生成スレッドがセマフォをリリースする前のハンドオフに対して、メモリへのダーティラインのフラッシュは必要とされない。

【0043】

ＯＳサポートによる実施例では、アクセラレータ上のメモリの割当て及び管理は、アプリケーションに与えられるシステムメモリページを割当て及び管理し、バーチャルアドレスを物理アドレスに変換するためＣＰＵにより用いられるページテーブルを管理するＯＳのメモリマネージャと協調して実行可能である。メモリマネージャはまた、リモートメモリにアクセスするためのリダイレクションによって行われる例外処理を処理し、ＣＰＵとアクセラレータとの間の物理ページの移動の背後にあるポリシーを管理する。ページ移動ポリシーは、ワークロードの動作に応じて可変的であり、潜在的にはリモートアクセスの回数を減少させるか（システムメモリへの対応するページの移動前に）、又はアクセス回数が最大となる位置にページを移動させるファーストタッチポリシーを実現するため変更可能である。コード及び読み出し専用データページは、物理ページの不要な移動を回避するため、複数のメモリに複製可能である。プログラムの実行中に処理されるデータを含むデータページのみが、データページへのアクセスのロカリティに基づき移動される。

【0044】

図７を参照して、本発明の一実施例によるプロセッサのブロック図が示される。図７に示されるように、プロセッサ５００は、マルチステージパイプラインアウトオブオーダプロセッサである。プロセッサ５００は、本発明の一実施例によるプロキシ実行及びリバースプロキシ実行に関連して用いられる各種特徴を示すため、図７において簡略化された図により示される。

【0045】

図７に示されるように、プロセッサ５００は、実行対象のマクロ命令をフェッチし、プロセッサにおける以降の利用のために準備するのに利用されるフロントエンドユニット５１０を有する。例えば、フロントエンドユニット５１０は、フェッチユニット５０４と、命令キャッシュ５０６と、命令デコーダ５０８とを有する。一部の実現形態では、フロントエンドユニット５１０はさらに、マイクロ処理ストレージと共にマイクロコードストレージと一緒にトレースキャッシュを有してもよい。フェッチユニット５０４は、メモリ又は命令キャッシュ５０６などからマクロ命令をフェッチし、それらをプリミティブ、すなわち、プロセッサによる実行用のマイクロ処理に復号化するため、命令デコーダ５０８に供給する。フロントエンドユニット５１０はさらに、ここに記載されるプロキシ実行及びリバースプロキシ実行を処理するための追加された状態情報を含むエントリを格納するため、本発明の一実施例によるＭＭＵ５０９を有する。このような情報に基づき、システムメモリと１以上のアクセラレータのローカルメモリとを含む共有バーチャルメモリスペースにおける各処理は、データを移動させるためのプログラムによるサポートなしに効率的に実行可能となる。

【0046】

マイクロ命令を受信し、実行用にそれらを準備するのに用いられるアウトオブオーダ（ＯＯＯ）エンジン５１５が、フロントエンドユニット５１０と実行ユニット５２０との間に接続される。より詳細には、ＯＯＯエンジン５１５は、マイクロ命令フローをリオーダし、実行に必要な各種リソースを割当て、レジスタファイル５３０及び拡張されたレジスタファイル５３５などの各種レジスタファイル内の記憶位置に論理レジスタのリネーミングを提供するための各種バッファを有する。レジスタファイル５３０は、整数及び浮動小数点演算のための別々のレジスタファイルを有する。拡張されたレジスタファイル５３５は、レジスタ毎に２５６又は５１２ビットなどのベクトルサイズ単位のストレージを提供する。

【0047】

各種リソースは、例えば、各種整数、浮動小数点、ＳＩＭＤ（Ｓｉｎｇｌｅ Ｉｎｓｔｒｕｃｔｉｏｎ Ｍｕｌｔｉｐｌｅ Ｄａｔａ）論理ユニット、特殊なハードウェアなどを含む実行ユニット５２０に存在する。結果は、リタイアメントロジック、すなわち、リオーダバッファ（ＲＯＢ）５４０に提供される。より詳細には、ＲＯＢ５４０は、実行される命令に係る情報を受信するための各種アレイ及びロジックを有する。この情報は、その後にＲＯＢ５４０により調べられ、命令が有効にリタイアされ、結果データがプロセッサのアーキテクチャ状態にコミット可能であるか、又は命令の適切なリタイアメントを回避する１以上の例外処理が実行されたか判断される。もちろん、ＲＯＢ５４０は、リタイアメントに係る他の処理を処理してもよい。

【0048】

図７に示されるように、ＲＯＢ５４０は、本発明の範囲はこれに限定されるものでないが、一実施例では低レベルキャッシュ（Ｌ１キャッシュなど）であってもよいキャッシュ５５０に接続される。また、実行ユニット５２０は、キャッシュ５５０に直接接続可能である。キャッシュ５５０から、データ通信がより高いレベルのキャッシュ、システムメモリなどにより実行される。図７の実施例にはこの高レベルにより示されるが、本発明の範囲がこれに限定されるものでないことは理解されるであろう。

【0049】

例えば、一部の実現形態では、アクセラレータはプロセッサとオンチップに一体化可能である。例えば、１つのアーキテクチャでは、多数の個別のプロセッサコアを、グラフィックスプロセッサ又は他の特殊な処理ユニットなどの異質なコアでありうるアクセラレータと共に含むマルチコアプロセッサであってもよい。一般に、プロキシ実行及びリバースプロキシ実行の処理は、コヒーラント又は非コヒーラントリンクを含む何れかのタイプのインターコネクトによりコアに接続されるオンチップアクセラレータに対して、上述したのと同様にして実行されてもよい。

【0050】

図８を参照して、本発明の他の実施例によるシステムのブロック図が示される。図８に示されるように、システム６００は、単一の半導体ダイ上に形成され、各種コンポーネントを含むマルチコアプロセッサ６１０を有する。具体的には、図８の実現形態では、プロセッサ６１０は、各コアがＴＬＢ６２５ａ〜６２５ｎを有し、上述されるような変換及び追加フィールドを有するエントリを含む複数のコア６２０ａ〜６２０ｎを有する。また、これらのコアは、各コアが自らのキャッシュメモリを有する点で、共有される最後のレベルのキャッシュである共有キャッシュ６４０に接続可能である。図示される実現形態では、このような２つのアクセラレータが示されるが、本発明の範囲はこれに限定されるものでない。アクセラレータとコアとの接続は、ＰＣＩｅ^ＴＭリンク、共有バスインターコネクトなどのコヒーラント又は非コヒーラントリンクなどの任意のタイプのインターコネクトによるものであってもよい。アクセラレータ６３０ａ，６３０ｂは、上述されるエントリを有するＴＬＢ６３５を有するよう示されている。さらに、プロセッサ６１０は、メモリコントローラ６５０を有する。

【0051】

一実現形態では、プロセッサ６１０はメモリ６６０に接続され、メモリ６６０は、プロセッサコアに関連付け可能な第１パーティション６６５ａと、アクセラレータに関連付け可能な第２パーティション６６５ｂとを含む複数のパーティションに分割可能なシステムメモリであってもよい。もちろん、コア及びアクセラレータに係るメモリは、異なるポートを介し異なるメモリモジュールとして異なって構成されてもよい。プロセッサ６１０はさらにチップセット６７０に接続され、チップセット６７０は入出力デバイス、記憶装置、他のアクセラレータなどの各種周辺装置に接続可能である。

【0052】

従って、コヒーラント又は非コヒーラントとすることができるリンクを介し接続されるアクセラレータ又は一体化されたアクセラレータを有することが可能な異なるシステムにおいて、プロキシ実行とリバースプロキシ実行とを処理するための実施例が提供できる。

【0053】

各実施例はコードにより実現され、命令を実行するようシステムをプログラムするのに利用可能な命令を格納する記憶媒体に格納されてもよい。この記憶媒体は、以下に限定されるものでないが、フロッピー（登録商標）ディスク、光ディスク、ソリッドステートドライブ（ＳＳＤ）、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ−ＲＷ（Ｃｏｍｐａｃｔ Ｄｉｓｋ−Ｒｅｗｒｉｔａｂｌｅ）、光磁気ディスクを含む何れかのタイプのディスク、ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）などの半導体デバイス、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリ、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）などのＲＡＭ、磁気若しくは光カード、又は電子命令を格納するのに適した他の何れかのタイプの媒体を含む。

【0054】

本発明が限定数の実施例に関して説明されたが、当業者は多数の改良及び変形を理解するであろう。添付した請求項はこのようなすべての改良及び変形を本発明の真の趣旨及び範囲内に属するものとしてカバーすることが意図される。

【符号の説明】

【0055】

１００ システム
１１０ プラットフォーム
１２０ ＣＰＵ
１３０ システムメモリ
１４０ インターコネクト
１５０ アクセラレータ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】