JP5347396B2 - マルチプロセッサシステム - Google Patents

マルチプロセッサシステム Download PDF

Info

Publication number
JP5347396B2
JP5347396B2 JP2008234313A JP2008234313A JP5347396B2 JP 5347396 B2 JP5347396 B2 JP 5347396B2 JP 2008234313 A JP2008234313 A JP 2008234313A JP 2008234313 A JP2008234313 A JP 2008234313A JP 5347396 B2 JP5347396 B2 JP 5347396B2
Authority
JP
Japan
Prior art keywords
memory
mapping
remote
processor node
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2008234313A
Other languages
English (en)
Other versions
JP2009087335A (ja
Inventor
弘臣 本橋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ricoh Co Ltd
Original Assignee
Ricoh Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ricoh Co Ltd filed Critical Ricoh Co Ltd
Priority to JP2008234313A priority Critical patent/JP5347396B2/ja
Publication of JP2009087335A publication Critical patent/JP2009087335A/ja
Application granted granted Critical
Publication of JP5347396B2 publication Critical patent/JP5347396B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
    • G06F12/0646—Configuration or reconfiguration
    • G06F12/0692—Multiconfiguration, e.g. local and global addressing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)

Description

本発明は、各々独立したメモリ空間が構成されるメモリを有する複数のプロセッサが接続される疎結合型のマルチプロセッサシステムに関する。
従来より、複数のプロセッサがメインメモリを共有する密結合型のマルチプロセッサシステムがある。このようなマルチプロセッサシステムでは、IntelやAMD社のx86 CPUのようなSMP（Symmetric Multi Processing）構成に対応しているプロセッサを採用することにより、比較的ローコストにマルチプロセッサシステムを構成することができる。このプロセッサは、単純にパフォーマンスが優れているだけでなくTCO（Total Cost of Ownership）の低減も同時に求められるようなシステムにおいて良く採用されている。しかし密結合型のマルチプロセッサシステムではプロセッサの数が増えて行くにつれてメモリへの負担が増大していく。このため、ある程度まではプロセッサ個数の増加に見合った分だけシステム全体の性能が向上していくものの、それ以上いくらプロセッサを増やしてもメモリへのアクセスがネックとなってしまうためにシステム全体の性能はあまり向上せずに飽和してしまう。つまり密結合型のマルチプロセッサシステムは、比較的小規模なシステムには向いているが、プロセッサを１００個以上も搭載するような大規模なマルチプロセッサシステムには適合性が悪い。
一方、複数台のプロセッサが各々独立したメインメモリを備えている疎結合型のマルチプロセッサシステムがある（例えば特許文献１参照）。このようなマルチプロセッサシステムでは、プロセッサの数が増加してもメモリへのアクセスが集中してシステム全体のパフォーマンスが飽和するようなことが起こらない。このため、疎結合型のマルチプロセッサシステムは、多くのプロセッサを搭載した大規模なマルチプロセッサシステムに適合している。
特開２００１−３３１４５７号公報
但し疎結合型のマルチプロセッサシステムでは、プロセッサ間の通信帯域や遅延時間（レイテンシ）の影響が問題となってくる。なぜなら、マルチプロセッサシステムに実行させたいシミュレーション等のタスクがあったとして、そのタスクを細分化して各プロセッサに割り当てたとしても、大抵はそれぞれの細分化されたタスク間で何らかの関連性や依存性が存在する。このために、各プロセッサ間で計算結果等の情報をやり取りする必要があるからである。このようなプロセッサ間での通信を可能とするために、従来からEthernet（登録商標）やInifiBand（登録商標）,Myrinet（登録商標）等のインターフェイスが利用されてきた。しかし、Ethernet(登録商標）には、以下のような問題があった。通信時のレイテンシ、即ち、送信元のプロセッサで動作しているプロセスがデータを送信してから、受信側のプロセッサで動作しているプロセスがデータを受け取るまでの時間が長いという問題である。また、通信を行う際のTCP/IP等のプロトコル処理が重いという問題である。通信時のレイテンシが長いと、プロセッサ間で頻繁にデータをやり取りするような場合には通信オーバーヘッドが増大してシステム全体のパフォーマンスが低下してしまう。またプロトコル処理が重いということは、貴重なCPUの性能が本来の目的（例えばシミュレーション計算等）以外の処理に無駄に浪費されてしまうということである。InfiniBandやMyrinetではレイテンシも短く、プロトコル処理がハードウェア化されているためにＣＰＵの処理負担が軽いという利点がある。しかし、これらを利用するインターフェイスカードはEthernet(登録商標）と比べると高機能・高性能であるがゆえに非常に高価であるため、ローコストが求められるマルチプロセッサシステムではInfiniBandやMyrinetは採用されることが少なかった。また密結合型のマルチプロセッサシステムにおいてプロセス間で大量のデータを受け渡す場合には共有メモリ・プログラミングモデルを利用するのが一般的であるが、InfiniBandやMyrinetはあくまでも高速な通信手段にしか過ぎないため、これらのインターフェイス上で共有メモリ機能を実現することはかなり困難である。よって密結合型マルチプロセッサシステム向けに開発されたソフトウェアを疎結合型マルチプロセッサシステムに移行させる場合、ソースコードに対して書き換えが行われていた。このため、ソフトウェアの開発効率が非常に低下してしまうという問題があった。
このため、パフォーマンスのスケーラビリティが良い疎結合型マルチプロセッサシステムにおいて、レイテンシが短く、ＣＰＵの処理負担が比較的軽いマルチプロセッサシステムが望まれていた。また、ソフトウェアの開発効率の低下を極力抑えることが望まれていた。
本発明は、上記に鑑みてなされたものであって、疎結合型マルチプロセッサシステムにおいて、レイテンシが短く、ＣＰＵの処理負担が比較的軽く、ソフトウェアの開発効率の低下を極力抑えることが可能なマルチプロセッサシステムを提供することを目的とする。
上述した課題を解決し、目的を達成するために、本発明は、マルチプロセッサシステムであって、各々独立したメモリ空間が構成されるメモリを各々有する複数のプロセッサノードが複数の通信回線を介して接続され、複数の前記プロセッサノードのそれぞれは、プログラムの実行により動作するプロセスからの要求に従って、自身の有する前記メモリにおいて構成されるメモリ空間に他のプロセッサノードのメモリの一部又は全部をリモートメモリとしてマッピングするメモリマッピングを行うメモリマッピング手段と、第１の通信回線を介して通信する第１通信手段と、第２の通信回線を介して通信する第２通信手段とを各々有し、複数の前記プロセッサノードのうち１つのプロセッサノードは、前記メモリマッピング手段が前記メモリマッピングを行う場合、前記プロセッサノードと前記他のプロセッサノードとの間のマッピングコネクションを作成するメモリマッピング管理手段を更に有し、前記メモリマッピング手段は、前記他のプロセッサノードの有する他のメモリマッピング手段に対して前記リモートメモリの割り当てを要求するメモリ割り当て要求を、前記第２通信手段を介して送信し、前記１つのプロセッサノードが有する前記メモリマッピング管理手段に対して前記マッピングコネクションの作成を要求するコネクション作成要求を、前記第２通信手段を介して送信し、前記メモリマッピング管理手段は、前記メモリマッピング手段から送信された前記コネクション作成要求に従って、前記プロセッサノードと前記他のプロセッサノードとの間のマッピングコネクションを作成した後、前記メモリマッピング手段に対して前記メモリマッピングの実行を指示するメモリマッピング指示を、前記１つのプロセッサノードが有する第１通信手段を介して送信することを特徴とする。
本発明は、上記の発明において、前記他のメモリマッピング手段は、前記リモートメモリの割り当てが要求された場合、前記他のプロセッサノードが有する他のメモリの全部又は一部のメモリ領域をリモートメモリとして割り当て、当該メモリ領域のアドレスを含むメモリ割り当て結果を、当該他のプロセッサノードが有する他の第２通信手段を介して前記メモリマッピング手段に送信することを特徴とする。
本発明は、上記の発明において、前記メモリマッピング手段は、前記他のメモリマッピング手段に対して前記メモリ割り当て要求を前記第２通信手段を介して送信した後、前記他のメモリマッピング手段が送信した前記メモリ領域のアドレスを含むメモリ割り当て結果を受信した場合、前記メモリマッピング管理手段に対して、前記メモリ領域のアドレスを含む前記コネクション作成要求を前記第２通信手段を介して送信し、前記メモリマッピング管理手段は、前記メモリマッピング手段が送信した前記コネクション作成要求に従って、前記プロセッサノードに対して設定されているメモリウィンドウのアドレスに対して前記メモリ領域のアドレスをマッピングすることによりマッピングコネクションを作成した後、前記メモリマッピング手段に対して前記メモリマッピングの実行を指示するメモリマッピング指示を、前記１つのプロセッサノードが有する第１通信手段を介して送信する
ことを特徴とする。
本発明は、上記の発明において、前記メモリマッピング手段は、前記メモリマッピング管理手段が送信した前記メモリマッピング指示を、前記第１通信手段を介して受信した場合、前記メモリ領域のアドレスについて、自身の有する前記メモリにおいて構成されるメモリ空間であり且つ前記プロセスにより生成される仮想メモリ空間にマッピングすることにより、前記メモリマッピングを行うことを特徴とする。
本発明は、上記の発明において、複数の前記プロセッサノードは、記憶手段に記憶されたＯＳ（Operating System）を読み出してこれを実行することにより当該プロセッサノードを制御する制御手段を各々有し、前記他のメモリマッピング手段は、前記ＯＳの起動時に、前記メモリにおいてアドレスが連続しているメモリ領域を確保し、前記メモリマッピング手段から前記リモートメモリの割り当てが要求された場合、確保したメモリ領域の一部又は全部をリモートメモリとして割り当て、当該メモリ領域のアドレスを含むメモリ割り当て結果を、前記他の第２通信手段を介して前記メモリマッピング手段に送信することを特徴とする。
本発明は、上記の発明において、前記メモリマッピング手段は、前記他のプロセッサノードの有する他のメモリマッピング手段に対して、前記リモートメモリのメモリサイズを指定して当該リモートメモリの割り当てを要求するメモリ割り当て要求を、前記第２通信手段を介して送信し、前記他のメモリマッピング手段は、前記メモリサイズが指定された前記リモートメモリの割り当てが要求されると、前記他のメモリのメモリ領域のうち前記メモリサイズのメモリ領域をリモートメモリとして割り当て、当該メモリ領域のアドレスを含むメモリ割り当て結果を、前記他のプロセッサノードが有する他の第２通信手段を介して前記メモリマッピング手段に送信することを特徴とする。
本発明は、上記の発明において、前記メモリマッピング手段は、Ｓｙｓｔｅｍ Ｖ ＩＰＣに含まれる共有メモリ機能が実現される際に用いられるＡＰＩと同等のＡＰＩを提供するメモリライブラリを含むことを特徴とする。
本発明は、上記の発明において、前記プロセッサノードに対して設定されているメモリウィンドウの一部又は全部は、まとめ書き込み可能なメモリ領域であることを特徴とする。
本発明は、上記の発明において、複数の前記プロセッサノードは、各々Ｐ２Ｐ（Peer to Peer）の関係で接続され、前記１つのプロセッサノードと、当該１つのプロセッサノード以外のプロセッサノードとはサーバとクライアントとの関係で接続されることを特徴とする。
本発明は、上記の発明において、前記第２の通信回線は、所定の通信規格に従って通信するためのネットワーク通信回線であることを特徴とする。
本発明は、上記の発明において、前記プロセッサノードは、Ｉ／Ｏ(Input/Output)デバイスに対してデータの書き込みを要求する書き込み要求を送るＣＰＵ（Central Processing Unit）と、前記ＣＰＵが接続されるホストバスと、前記Ｉ／Ｏデバイスが接続される汎用バスと、前記ホストバスと前記汎用バスとを接続するホストバスブリッジと、前記ＣＰＵと前記ホストバスブリッジとの間に設けられたライトバッファとを有し、前記ライトバッファは、前記ＣＰＵから送られる前記書き込み要求をバッファリングして、前記汎用バスに対してバースト転送サイクルを発行することを特徴とする。
本発明によれば、レイテンシが短く、ＣＰＵの処理負担が比較的軽くすることができる。また、共有メモリ・プログラミングモデルを利用可能にすることができ、ソフトウェアの開発効率の低下を極力抑えることができる。
以下に添付図面を参照して、この発明にかかるマルチプロセッサシステムの最良な実施の形態を詳細に説明する。
[第１の実施の形態]
（１）構成
図１は本実施の形態にかかる共有メモリ型のマルチプロセッサシステムの構成を示す図である。本実施の形態にかかるマルチプロセッサシステムＳＹＭは、一例として３つのプロセッサノード５０Ａ〜５０Ｃが通信回線５１と、通信回線５２とを介して各々接続される。プロセッサノード５０Ａは、ＣＰＵ（Central Processing Unit）５００Ａと、メインメモリ５０１Ａとの対を有し、Ｅｔｈｅｒｎｅｔ(登録商標）カード５０４Ａと、メモリマッピングカード５０５Ａとを有する。プロセッサノード５０Ａは、Ｅｔｈｅｒｎｅｔ(登録商標）カード５０４Ａ及び通信回線５２を介して他のプロセッサノード５０Ｂ〜Ｃと通信を行い、Ｅｔｈｅｒｎｅｔ(登録商標）カード５０４Ａ及び通信回線５１を介して他のプロセッサノード５０Ｂ〜Ｃと通信を行う。プロセッサノード５０Ｂ、５０Ｃについても同様である。尚、プロセッサノード５０Ａは、ルートノードとして機能し、プロセッサノード５０Ｂ〜５０Ｃは、リーフノードとして機能するものとする。そして、ルートノード５０Ａはサーバとし、プロセッサノード５０Ｂ〜５０Ｃはクライアントとして各々接続される。また、ルートノード５０Ａと、プロセッサノード５０Ｂ〜５０Ｃとは各々Ｐ２Ｐで接続される。
図２はプロセッサノード５０Ａ〜５０Ｃの具体的なハードウェア構成を示す図である。尚、プロセッサノード５０Ａ〜５０Ｃを区別する必要がない場合には、単にプロセッサノード５０と記載する。また、各プロセッサノード５０Ａ〜５０Ｃの有する構成要素に対する符号についても同様に、これらを区別する必要がない場合には、各符号に「Ａ」〜「Ｃ」を付加せず、これらを区別する必要がある場合には符号の後ろに「Ａ」〜「Ｃ」を付加して記載する。プロセッサノード５０は、上述したＣＰＵ５００と、メインメモリ５０１と、Ｅｔｈｅｒｎｅｔ(登録商標）カード５０４と、メモリマッピングカード５０５と、メモリコントローラ５０２と、ホスト−ＰＣＩブリッジ５０３と、ＰＣＩデバイス５０６〜５０７とを有する。ＣＰＵ５００は、メインメモリ５０１に記憶された各種プログラムを実行することによりプロセッサノード５０全体を制御する。また、ＣＰＵ５００は、ＭＭＵ（Memory Management Unit）（図示せず）を有し、ＭＭＵにより、ページテーブルを利用したページング機能を実現させる。メインメモリ５０１は、各種データや各種プログラムを記憶する記憶装置であり、例えばＲＡＭ（Random Access Memory）により構成される。Ｅｔｈｅｒｎｅｔ(登録商標）カード５０４は、Ｅｔｈｅｒｎｅｔ(登録商標）の規格に準拠したデータ通信を中継する。メモリマッピングカード５０５は、後述するメモリマッピングが行われたリモートメモリに対するデータ通信を中継する。
メモリコントローラ５０２は、ホストバス５１０を介してＣＰＵ５００と接続され、ＣＰＵ５００からメインメモリ５０１やＥｔｈｅｒｎｅｔ(登録商標）カード５０４Ａやメモリマッピングカード５０５ＡなどのＩ／Ｏ(Input/Output)デバイスに対する読み出し又は書き込みの要求を受け取ると、対象のデバイスに対してリクエストを振り分ける。例えば、Intel製のx86 CPUを搭載したコンピュータでは、メイン基板であるマザーボード上に搭載された、ノースブリッジやMCH（Memory Controller Hub）と呼ばれるチップセットがメモリコントローラ５０２に相当する。
ホスト−ＰＣＩブリッジ５０３は、ＣＰＵ５００からＰＣＩデバイス５０６〜５０７に対するアクセス要求を発行したり、あるいはＰＣＩデバイス５０６〜５０７からメインメモリ５０１に対するＤＭＡリクエストを受け取ってメモリコントローラ５０２に伝えたりする。上述したIntel製のx86 CPUを搭載したコンピュータでは、サウスブリッジやICH（I/O Controller Hub）と呼ばれるチップセットがホスト−ＰＣＩブリッジ５０３に相当する。
図３は、プロセッサノード５０を構成するハードウェアとメモリ空間との対応関係を示す図である。メモリ空間６００では、メインメモリ５０１のアドレスは低位側のアドレス空間６０１にマッピングされている。リモートメモリ６０２は、メインメモリ５０１のアドレスは低位側のアドレス空間６０１の一部又は全部の領域であり、他のプロセッサノード５０と共有されるメモリ領域である。メモリウィンドウ６０３は、メモリ空間６００の高位側のアドレス空間の一部の領域にマッピングされる。メモリウィンドウ６０３は、他のプロセッサノード５０のメインメモリ５０１（以降、リモートメモリという）の一部又は全部のメモリ領域のアドレスがマッピングされることにより、プロセッサノード５０の有するＣＰＵ５００やＰＣＩデバイス５０６〜５０７が他のプロセッサノード５０のリモートメモリに対してデータの読み出し及び書き込み等のアクセスを行うことができるものとしてプロセッサノード５０に設定されるメモリ領域である。各プロセッサノード５０は、Ethernet(登録商標）カード５０４を介して、メモリマッピングに関するデータを送受信し、メモリマッピングカード５０５を介して、メモリウィンドウ６０３に書き込まれたデータを送受信する。
次に、プロセッサノード５０のソフトウェア構成について説明する。以降、説明の便宜上、プロセッサノード５０Ａをルートノード５０Ａと記載し、プロセッサノード５０Ｂ〜５０Ｃを各々リーフノード５０Ｂ〜５０Ｃと記載する。図４は、リーフノード５０Ｂのソフトウェア構成を例示する図である。リーフノード５０Ｂのソフトウェア構成は、ユーザプログラム８０１Ｂと、メモリライブラリ８０２Ｂと、メモリデーモン８０３Ｂと、ＯＳ（オペレーティングシステム）８０４Ｂと、メモリデバイスドライバ８０５Ｂとを含む。これらは例えばメインメモリ５０１Ｂに記憶され、ＣＰＵ５００Ｂによりメインメモリ５０１Ｂから読み出されて実行されることにより、以下に説明する各種機能が実現される。
ユーザプログラム８０１Ｂは、各種のアプリケーションプログラムであり、ＣＰＵ５００Ｂにより実行されることにより、各種プロセスがプロセッサノード５０Ｂにおいて動作することになる。また、ユーザプログラム８０１Ｂは、共有メモリ（リモートメモリ）を利用する際に、リモートメモリとして使用するメモリ領域を割り当てるための共有メモリキーと共有メモリファイルとをメモリデーモン８０３Ｂに対して指定する。共有メモリキーとは、利用対象のリモートメモリを有するプロセッサノードを指定するための情報である。共有メモリファイルとは、メモリデーモン８０３Ｂが使用するポート番号や、後述する共有メモリＩＤ管理テーブルのパス名や、ネットワークインターフェイス名や、プロセッサノードを特定するノードＩＤとＩＰアドレスとの対応関係などを示すものである。
ＯＳ８０４Ｂは、プロセス間で通信を行うための機能として、後述するソケットや共有メモリといったIPC（Inter-Process Communication）を実現する機能を有する。また、ＯＳ８０４Ｂは、ＣＰＵ５００Ｂの有するＭＭＵを利用してメモリ空間の物理アドレスをページ単位（例えば、4KB）でプロセスが動作する仮想メモリ空間の論理アドレスにマッピングするページングと呼ばれるメモリ管理を行う。また、ＯＳ８０４Ｂは、ＴＣＰ／ＩＰプロトコルスタックを有する。
メモリライブラリ８０２Ｂは、メモリデーモン８０３Ｂのインターフェイスを隠蔽し、例えば、UNIX(登録商標）においてプロセス間のデータ共有手段として一般的に利用されているSystem V IPCに含まれる共有メモリ機能のためのＡＰＩと同等のＡＰＩをユーザプログラムに対して提供する。また、メモリライブラリ８０２Ｂは、リモートメモリとして使用するメモリ領域の割り当てをメモリデーモン８０３Ｂに対して要求する。要求先のプロセッサノードは、ユーザプログラム８０１Ｂから指定された共有メモリキーと共有メモリファイルとに従って決定される。また、メモリライブラリ８０２は、メモリマッピングカード５０５Ｂのコネクションの作成及び削除をルートノード（プロセッサノード５０Ａ）のメモリデーモン８０３Ｂに対して要求する。また、メモリライブラリ８０２Ｂは、リモートメモリ６０２Ｃのアドレスについて、メインメモリ５０１Ｂのメモリ空間へのマッピングをメモリデバイスドライバ８０５Ｂに対して要求する。
メモリデーモン８０３Ｂは、リモートメモリとして使用するメモリ領域の割り当てをメモリデバイスドライバ８０５Ｂに対して要求する。メモリデーモン８０３Ｂは、共有メモリＩＤ管理テーブルに格納されているデータを維持・管理する責務を負っている。共有メモリＩＤ管理テーブルは、共有メモリキーとリモートメモリとの対応関係を示す情報である。また、メモリデーモン８０３Ｂは、割り当てたリモートメモリのメモリクリア処理を行う。
図５は、共有メモリＩＤ管理テーブルのデータ構成を例示する図である。共有メモリＩＤ管理テーブルは、例えばメインメモリ５０１Ｂに記憶される。共有メモリＩＤ管理テーブルにおいては、共有メモリＩＤと、ステータスと、共有メモリキーと、リモートメモリを有するプロセッサノードを特定するノードＩＤ（リモートノードＩＤ）と、リモートメモリのアドレスと、参照カウントとを対応付けて記憶される。共有メモリＩＤとは、メモリの割り当てを管理するためのＩＤである。ステータスは、メモリの割り当てが行われたリモートメモリの使用状況を示すデータである。参照カウントは、リモートメモリに対するアクセス数を示すデータである。
メモリデバイスドライバ８０５Ｂは、IOCTLの呼び出しによって、リモートメモリとして使用するメモリ領域の割り当て及び解放処理を行う。メモリデバイスドライバ８０５Ｂは、mmap()システムコールの呼び出しによって、リモートメモリ６０２Ｃのアドレスについてリーフノード５０Ｂ自身のメインメモリ５０１Ｂ（ローカルメモリ）のメモリ空間へのメモリマッピングを行う。また、メモリデバイスドライバ８０５Ｂは、mmap()システムコールの呼び出しによって、PCIアドレス空間上に存在するメモリウィンドウのメモリ空間へのメモリマッピングを行う。また、メモリデバイスドライバ８０５Ｂは、ＯＳ８０４Ｂの起動時にメインメモリ５０１Ｂにおいて物理アドレスが連続的となるようメモリ領域をメモリプールとして確保する。そして、メモリデバイスドライバ８０５Ｂは、確保したメモリ領域のうち一部又は全部をリモートメモリとして使用する場合に当該メモリ領域を管理するための連続物理メモリ管理テーブルへの情報の記憶やアクセスを制御する。
図６〜７は、連続物理メモリ管理テーブルのデータ構成を例示する図である。連続物理メモリ管理テーブルは、例えばメインメモリ５０１Ｂに記憶される。連続物理メモリ管理テーブルにおいては、メモリ領域の使用状況を示すステータスと、メモリ領域のアドレスと、メモリ領域のメモリサイズとが対応付けられて記憶される。例えば、アドレスが「0X3000 0000」でありメモリサイズが４ＭＢのメモリ領域がリモートメモリとして使用される場合、メモリデバイスドライバ８０５Ｂは、図７に示されるように、当該メモリ領域に対して、ステータス「使用中」及びメモリサイズ「４ＭＢ」として連続物理メモリ管理テーブルに記憶する。
尚、リーフノード５０Ｃのソフトウェア構成はリーフノード５０Ｂのものと同様であるため、その図示及び説明を省略する。但し、以降では、リーフノード５０Ｃのソフトウェア構成に含まれる各構成要素の符号については、リーフノード５０Ｂのものと区別するため、リーフノード５０Ｂのソフトウェア構成に含まれる各構成要素の符号「Ｂ」を「Ｃ」に変えたものを用いる。
図８は、ルートノード５０Ａのソフトウェア構成を例示する図である。上述のリーフノード５０Ｂのソフトウェア構成と共通する部分については説明を省略する。ルートノード５０Ａのソフトウェア構成は、ユーザプログラム８０１Ａと、メモリライブラリ８０２Ａと、メモリデーモン８０３Ａと、ＯＳ８０４Ａと、メモリデバイスドライバ８０５Ａとに加え、メモリマッパ管理デーモン８０６Ａを含む。メモリデーモン８０３Ａは、上述の機能に加え、メモリマッピングカード５０５Ａのコネクションの作成及び削除をメモリマッパ管理デーモン８０６Ａに対して要求する。また、メモリデーモン８０３Ａは、メモリウィンドウとリモートメモリとの対応関係を示すメモリウィンドウ管理テーブルへのデータの記憶やアクセスを制御する。
図９〜図１０は、メモリウィンドウ管理テーブルのデータ構成を例示する図である。メモリウィンドウ管理テーブルは、例えばメインメモリ５０１Ａに記憶される。メモリウィンドウ管理テーブルにおいては、図９に示されるように、メモリウィンドウに関する情報として、リモートメモリを利用するプロセッサノードを特定するノードＩＤと、メモリウィンドウの使用状況を示すステータスと、メモリウィンドウのアドレスと、メモリサイズとが予め記憶されている。そして、メモリウィンドウに対してリモートメモリがマッピングされると、図１０に示されるように、メモリウィンドウに関する情報に対して、リモートメモリに関する情報として、リモートメモリを有するプロセッサノードを特定するノードＩＤ（リモートノードＩＤ）と、リモートメモリのアドレスとが対応付けられ記憶される。また、メモリウィンドウに関する情報として対応付けられて記憶されるステータスは「使用中」であることを示すものとなる。
メモリマッパ管理デーモン８０６Ａは、メモリマッピングコネクションの作成及び削除を行う。即ち、ルートノード５０Ａは、メモリマッパ管理デーモン８０６Ａの機能により、リーフノード５０Ｂ〜５０Ｃからの要求に応じて、メモリマッピングコネクションを作成したり削除したりする。
図１１は、マルチプロセッサシステムＳＹＭにおいて、メモリマッピングを行いリモートメモリへアクセスする処理の手順を概念的に示す図である。ルートノード５０Ａと、リーフノード５０Ｂ〜５０Ｃとの通信回線５１を介した通信は、メモリマッピングスイッチ５３を介して行われる。リーフノード５０Ｂが、リーフノード５０Ｃのリモートメモリにアクセスする場合、通信回線５２を介して、リーフノード５０Ｃに対してリモートメモリの割り当てを要求し（ＳＴ１）、ルートノード５０Ａに対してメモリマッピングコネクションの作成を要求する（ＳＴ２）。ルートノード５０Ａは、当該要求に応じて、メモリウィンドウ６０３Ｂに対してリモートメモリ６０２Ｃをマッピングするメモリマッピングコネクションを作成し、通信回線５１を介してリーフノード５０Ｂに対してメモリマッピングを指示する（ＳＴ３）。そして、リーフノード５０Ｂは、リモートメモリ６０２Ｃについてメインメモリ５０１Ｂのメモリ空間へマッピングするメモリマッピングを行う。この結果、リーフノード５０Ｂは、通信回線５１を介して、リーフノード５０Ｃのリモートメモリ６０２Ｃに対してアクセスすることができる(ＳＴ４)。
図１２は、以上のようにマッピングが行われたリモートメモリ６０２Ｃに対してリーフノード５０Ｂがアクセスする場合の様子を例示する図である。プロセス７００Ｂは、プロセッサノード５０Ｂの有するユーザプログラム８０１ＢをＣＰＵ５００Ｂが実行することにより動作するものである。プロセス７００Ｃは、プロセッサノード５０Ｃの有するユーザプログラム８０１ＣをＣＰＵ５００Ｃが実行することにより動作するものである。例えば、プロセッサノード５０Ｂで動作しているプロセス７００Ｂがメモリウィンドウ６０３Ｂの領域に対して書き込みを行うと（ＳＴ１０）、書き込みを行ったデータとアドレスとがリーフノード５０Ｃにメモリマッピングカード５０５Ｃ，５０５Ｂを介して送信され、リーフノード５０Ｃのリモートメモリ６０２Ｃに対して書き込み処理が行われる（ＳＴ１１）。このリモートメモリ６０２Ｃに対してリーフノード５０Ｃで動作しているプロセス７００Ｃが読み出しを行うことにより（ＳＴ１２）、リーフノード５０Ｂからリーフノード５０Ｃに対してデータを伝達することが可能となる。
図１３は、以上のようにしてリーフノード５０Ｂがリーフノード５０Ｃの有するメインメモリ５０１のリモートメモリ６０２Ｃに対して書き込みを行った場合のデータフローを例示する図である。同図に示されるように、リーフノード５０ＢのＣＰＵ５００Ｂがリーフノード５０Ｃのリモートメモリ６０２Ｃに対して書き込みを行うデータとそのアドレスとは、メモリマッピングカード５０５Ｂ、通信回線５１及びメモリマッピングカード５０５Ｃを介してＣＰＵ５００Ｃに受け取られ、ＣＰＵ５００Ｃによりメインメモリ５０１Ｃに書き込まれる。
図１４はリーフノード５０Ｂ〜５０Ｃ間でプロセスがソケット通信を利用して通信している様子を示す図である。リーフノード５０Ｃで動作するプロセス７００Ｃがソケット書き込みを行い（ＳＴ２０）、リーフノード５０Ｂで動作するプロセス７００Ｂがソケット読み出しを行うことにより（ＳＴ２１）、通信が行われる。ソケットはネットワークを透過する通信手段であるため、マルチプロセッサシステムＳＹＭを構成している任意のプロセッサノード間でプロセスが双方向に通信を行うことができる。
図１５はソケット通信時のデータフローを示す図である。ソケットを流れるデータ（ソケット通信データ）はＯＳ８０４内にある例えばＴＣＰ／ＩＰプロトコルスタックによってフレーム単位に分割される。Ethernet(登録商標）カード５０４を介した通信回線５１での通信ではフレーム単位でデータが送受信されている。例えば送信側のEthernet(登録商標）カード５０４Ｃはメインメモリ５０１Ｃ上に書き込まれたフレームデータを読み出して送信処理を行い、フレームを受け取ったEthernet(登録商標）カード５０４Ｂはフレーム内のデータをメインメモリ５０１Ｂに書き込み、ＣＰＵ５００Ｂに対して割り込み等によってフレームの到着を通知する。尚、チェックサム等のエラー検出メカニズムによりメインメモリ５０１上のフレームデータの正当性を確認したり、分割して受信したフレームデータを統合して元のソケット通信データにまとめたりするのはＴＣＰ／ＩＰプロトコルスタックの役目である。
尚、プロセス間でのメモリ保護機能を持っているUNIX(登録商標）のようなＯＳではプロセス間でグローバル変数等を通してデータの伝達を行うことができない。このため、上述したように、ＯＳ８０４は、プロセス間で通信を行うための機能として、ソケットや共有メモリといったIPC（Inter-Process Communication）を実現する機能を有している。ソケットはネットワーク透過な機能なので、プロセッサノード内のみならずプロセッサノード間でデータをやり取りする場合にも使用することができるという長所がある。その反面、ソフトウェアオーバーヘッドが多いために大量のデータ交換には向かないという欠点もある。共有メモリはオーバーヘッドが低く大量のデータ交換でも効率良く行えるが（広帯域）、通常はプロセッサノード内でしか利用できない。このため、複数のプロセッサノードによって構成されるマルチプロセッサシステムではあまり利用されることがなかった。図１２の例のように、別々のリーフノード５０Ｂ，５０Ｃで各々動作しているプロセス７００Ｂ，７００Ｃの間でリモートメモリ６０２Ｃを共用することでデータの伝達を行うことが可能にすることで、分散共有メモリが実現される。分散共有メモリは、プロセッサノード間で利用できるというソケットの長所と、広帯域であるという共有メモリのメリットとを併せ持っている。
図１６は、リーフノード５０Ｂが、リーフノード５０Ｃに対してリモートメモリ６０２Ｃのメモリ領域の割り当てを要求する際の様子を示す図である。プロセッサノード５０Ｂのユーザプログラム８０１Ｂは、上述のソケット通信を利用して、Ethernet(登録商標）カード５０４Ｂ,通信回線５２及びEthernet(登録商標）カード５０４Ｃを介して、リモートメモリ６０２Ｃを有するプロセッサノード５０Ｃのメモリデーモン８０３Ｃに対してメモリ割り当て要求を送信する（ＳＴ３０）。メモリデーモン８０３Ｃは、メインメモリ５０１Ｃの一部又は全部のメモリ領域をリモートメモリとして確保し、ソケット通信を利用して、確保したメモリ領域の物理アドレスを含むメモリ割り当て応答をリーフノード５０ＢのユーザプログラムＢに送信する（ＳＴ３１）。
図１７は、リーフノード５０Ｂが、ルートノード５０Ａに対してリモートメモリ６０２Ｃのメモリマッピングを要求する際の様子を例示する図である。リーフノード５０Ｂのユーザプログラム８０１Ｂが、Ethernet(登録商標）カード５０４Ｂ,通信回線５２及びEthernet(登録商標）カード５０４Ａを介してルートノード５０Ａのメモリマッパ管理デーモン８０６Ａに対して、メモリウィンドウ６０３Ｂに対してリモートメモリ６０２Ｃをマッピングすることを要求するメモリマッピング要求を送信する（ＳＴ３２）。メモリマッパ管理デーモン８０６Ａは、メモリデバイスドライバ８０５、メモリマッピングカード５０５Ａ、通信回線５１及びメモリマッピングカード５０５Ｂを介してリーフノード５０Ｂのメモリマッピングカード５０５Ｂに対して、リモートメモリ６０２Ｃについてメインメモリ５０１のメモリ空間にマッピングすることを指示するメモリマッピング指示を送信する（ＳＴ３３）。
そして、例えば、図１８に示すようにプロセッサノード５０Ｃのメインメモリ５０１Ｃの一部であるリモートメモリ６０２Ｃが、プロセッサノード５０Ｂのメモリウィンドウ６０３Ｂにマッピングされる。この結果、プロセッサノード５０Ｂで動作しているプロセス７００Ｂが、プロセッサノード５０Ｃのメインメモリ５０１Ｃの一部であるリモートメモリ６０２Ｃに対して直接アクセスすることができるようになる。尚、マルチプロセッサシステムＳＹＭに更に他のリーフノードが接続され、当該他のリーフノード上のメインメモリをリモートメモリとして利用する場合であっても、リーフノード５０Ｂとリーフノード５０Ｃとの関係は変わらない。他のリーフノードにおけるメモリマッピングは、他のリーフノードからルートノード５０Ａに対してメモリマッピングを要求することにより実現されるものである。また、ルートノード５０Ａ自体がリモートメモリを有するようメモリマッピングを行うこともできる。
（２）動作
次に、本実施の形態にかかるマルチプロセッサシステムＳＹＭの動作について説明する。まず、リーフノード５０Ｂがリーフノード５０Ｃのリモートメモリ６０２Ｃにアクセスする場合の処理の手順について説明する。図１９は、リーフノード５０Ｂがリーフノード５０Ｃのリモートメモリ６０２Ｃにアクセスする場合のシーケンスチャートである。リーフノード５０Ｂのメモリデバイスドライバ８０５Ｂは、ＯＳ８０４Ｂの起動時に、メインメモリ５０１Ｂにおいて、リーフノード５０Ｂ自身のリモートメモリのためのメモリ領域を物理アドレスが連続的となるようメモリプールとして確保する（ステップＳ１）。リーフノード５０Ｃについても同様に、ＯＳ８０４Ｃの起動時に、メモリデバイスドライバ８０５Ｃが、メインメモリ５０１Ｃにおいて、リモートメモリ６０２Ｃのためのメモリ領域を物理アドレスが連続的となるようメモリプールとして確保する（ステップＳ２）。そして、リーフノード５０Ｂのユーザプログラム８０１Ｂは、リモートメモリ６０２Ｃの割り当てを要求すべく、共有メモリキー及び割り当てるメモリサイズを含むメモリ割り当て要求をメモリライブラリ８０２Ｂに送る（ステップＳ３）。またこのときユーザプログラム８０１Ｂは共有メモリファイルを送る。メモリライブラリ８０２Ｂはメモリ割り当て要求を受け取ると、共有メモリキー及び割り当てるメモリサイズを含むメモリ割り当て要求をリーフノード５０Ｃに対して送信する（ステップＳ４）。
一方、リーフノード５０Ｃのメモリデーモン８０３Ｃは、メモリの割り当て要求を受信すると、これをメモリデバイスドライバ８０５Ｃに送り（ステップＳ５）、メモリデバイスドライバ８０５Ｃは、メモリ割り当て要求に従って、要求されたメモリサイズのメモリ領域をリモートメモリ６０２Ｃとして割り当てる（ステップＳ６）。そして、メモリデバイスドライバ８０５Ｃは、図７に示したように、割り当てたメモリ領域のアドレス及びメモリサイズと、「使用中」であることを示すステータスとを連続物理メモリ管理テーブルに記憶する。次いで、メモリデバイスドライバ８０５Ｃは、割り当てたリモートメモリ６０２Ｃのアドレスを含むメモリ割り当て結果をメモリデーモン８０３Ｃに送り（ステップＳ７）、メモリデーモン８０３Ｃはこれをリーフノード５０Ｂに送信する（ステップＳ８）。
リーフノード５０Ｂのメモリライブラリ８０２Ｂは、メモリの割り当て結果を受信すると（ステップＳ９）、上述の共有メモリキーに対して共有メモリＩＤを採番し当該共有メモリＩＤ及び共有メモリキーと、メモリ割り当て結果に含まれる、リモートメモリ６０２Ｃのアドレスと、リモートメモリ６０２Ｃを有するプロセッサノード（ここではリーフノード５０Ｃである）を特定するリモートノードＩＤとを対応付けて共有メモリＩＤ管理テーブルに記憶する。そして、メモリライブラリ８０２Ｂは、共有メモリＩＤを含むメモリ割り当て結果をユーザプログラム８０１Ｂに送る（ステップＳ９）。ユーザプログラム８０１Ｂは、共有メモリＩＤを含むメモリ割り当て結果を受け取ると（ステップＳ１０）、メモリマッピング要求として、当該共有メモリＩＤを含むメモリアタッチ要求をメモリライブラリ８０２Ｂに送る（ステップＳ１１）。メモリライブラリ８０２Ｂは、共有メモリＩＤに対応して共有メモリＩＤ管理テーブルに記憶されているリモートノードＩＤ及びリモートメモリ６０２Ｃのアドレスを含むメモリマッピング要求をルートノード５０Ａに送信する（ステップＳ１２）。
ルートノード５０Ａのメモリデーモン８０３Ａは、リモートノードＩＤ及びリモートメモリ６０２Ｃのアドレスを含むメモリマッピング要求を受信すると、メモリマッパ管理デーモン８０６Ａに対して、メモリマッピング要求を送信したプロセッサノードのノードＩＤと、メモリマッピング要求に含まれるリモートノードＩＤ及びリモートメモリ６０２Ｃのアドレスを送り、マッピングコネクションの作成を要求する（ステップＳ１３）。メモリマッパ管理デーモン８０６Ａは、当該要求に従って、メモリウィンドウ６０３Ｂのアドレスに対してリモートメモリ６０２Ｃのアドレスをマッピングするマッピングコネクションを作成する処理を行い（ステップＳ１４）、その処理結果として、リモートメモリ６０２Ｃのアドレスを含むマッピングコネクション作成結果をメモリデーモン８０３Ａに送る（ステップＳ１５）。メモリデーモン８０３Ａは、当該マッピングコネクション作成結果をリーフノード５０Ｂに送信する（ステップＳ１６）。尚、このマッピングコネクション作成結果により、リモートメモリ６０２Ｃのアドレスについてメインメモリ５０１Ｂのメモリ空間へマッピングすることがリーフノード５０Ｂに対して指示される。また、メモリデーモン８０３Ａは、メモリウィンドウ管理テーブルにおいて、メモリマッピングの要求元のプロセッサノード（ここでは、リーフノード５０Ｂである）のノードＩＤと、メモリマッピング対象のメモリウィンドウ６０３Ｂのアドレスと、メモリサイズと、リモートノードＩＤと、リモートメモリ６０２Ｃのアドレスと、「使用中」であることを示すステータスとを対応付けて記憶する。
リーフノード５０Ｂのメモリライブラリ８０２Ｂは、当該マッピングコネクション作成結果をメモリマッピング結果として受け取ると、メモリデバイスドライバ８０５Ｂに対して、リモートメモリ６０２Ｃのアドレスを送ってメモリマッピングを要求する（ステップＳ１７）。メモリデバイスドライバ８０５Ｂは、当該要求に従って、リモートメモリ６０２Ｃのアドレスについてメインメモリ５０１Ｂのメモリ空間へマッピングするメモリマッピングを行う。このメモリ空間とは、ユーザプログラム８０１Ｂの実行により動作するプロセスにより生成される仮想メモリ空間である。そして、メモリデバイスドライバ８０５Ｂは、メモリマッピング結果をメモリライブラリ８０２に送る（ステップＳ１８）。メモリライブラリ８０２Ｂは、当該メモリマッピング結果をメモリアタッチ結果としてユーザプログラム８０１に送る（ステップＳ１９）。ユーザプログラム８０１Ｂは、メモリアタッチ結果を受け取ると（ステップＳ２０）、メモリマッピングカード５０５Ｂ及び通信回線５１を介してリモートメモリ６０２Ｃにアクセス可能になる。
次に、図１９に示した処理のうち、メモリライブラリ８０２Ｂと、メモリデーモン８０３Ａ，８０３Ｃと、メモリデバイスドライバ８０５Ｂ，８０５Ｃとが各々行う処理の手順について詳細に説明する。
図２０は、リーフノード５０Ｂのメモリライブラリ８０２Ｂが上述のステップＳ４，Ｓ９で行う処理の詳細な手順を示すフローチャートである。上述のステップＳ４では、メモリライブラリ８０２Ｂは、共有メモリキー及びメモリサイズを含むメモリ割り当て要求及び共有メモリファイルがユーザプログラム８０１Ｂから送られると、共有メモリキー及び共有メモリファイルを用いて、利用対象のリモートメモリ６０２Ｃを有するプロセッサノード（ここでは、リーフノード５０Ｃである）を決定する（ステップＳ３０）。そして、メモリライブラリ８０２Ｂは、リーフノード５０Ｃのメモリデーモン８０３Ｃに対して、共有メモリキー及びメモリサイズを含むメモリ割り当て要求を送信する（ステップＳ３１）。
そして、上述のステップＳ９では、メモリライブラリ８０２Ｂは、リーフノード５０Ｃから、リモートメモリ６０２Ｃのアドレスを含むメモリ割り当て結果を受信すると、未使用の共有メモリＩＤを採番し、当該共有メモリＩＤ及びリモートメモリのアドレスを対応付けて共有メモリＩＤ管理テーブルに記憶すると共に（ステップＳ３２）、当該共有メモリＩＤを含むメモリ割り当て結果をユーザプログラム８０１Ｂに送る（ステップＳ３３）。
図２１は、リーフノード５０Ｃのメモリデーモン８０３Ｃが上述のステップＳ５，Ｓ８で行う処理の詳細な手順を示すフローチャートである。上述のステップＳ５では、メモリデーモン８０３Ｃは、共有メモリキー及びメモリサイズを含むメモリ割り当て要求をプロセッサノード５０Ｂから受信すると、当該共有メモリＩＤについてステータスが「使用中」であるとして共有メモリＩＤ管理テーブルに記憶されているか否かを判断する（ステップＳ４０）。ここでは、メモリの割り当て要求であり、当該共有メモリＩＤは未だ記憶されていないとして、当該判断結果があるとする。この場合、メモリデーモン８０３Ｃは、上述のメモリ割り当て要求に含まれるメモリサイズのメモリ領域であり、物理アドレスが連続しているメモリ領域をリモートメモリ６０２Ｃとして割り当てることをメモリデバイスドライバ８０５Ｃに対して要求する（ステップＳ４１）。そして、メモリデーモン８０３Ｃは、共有メモリＩＤ管理テーブルにおいて当該共有メモリＩＤに対応するメモリ参照カウントを「１」として記憶する（ステップＳ４２）。
そして、上述のステップＳ８では、メモリデーモン８０３Ｃは、ステップＳ４１の要求に従って割り当てられたメモリ領域の物理アドレスをメモリデバイスドライバ８０５Ｃから受け取ると、当該物理アドレスを含むメモリ割り当て結果をリーフノード５０Ｂに送信する。
尚、ステップＳ４０の判断結果が肯定的である場合、リモートメモリ６０２Ｃへのアクセスが要求されている場合であり、この場合、メモリデーモン８０３Ｃは、共有メモリＩＤ管理テーブルに共有メモリＩＤに対応付けられて記憶されているメモリ参照カウントを「１」インクリメントする（ステップＳ４４）。そして、メモリデーモン８０３Ｃは、共有メモリＩＤ管理テーブルにおいて当該共有メモリＩＤに対応付けられている物理アドレスを含むメモリ割り当て結果をリーフノード５０Ｂに送信する（ステップＳ４５）。
図２２は、リーフノード５０Ｃのメモリデバイスドライバ８０５Ｃが上述のステップＳ６，Ｓ７で行う処理の詳細な手順を示すフローチャートである。ステップＳ７では、メモリデバイスドライバ８０５Ｃは、上述のメモリ割り当て要求に含まれるメモリサイズのメモリ領域であり、物理アドレスが連続しているメモリ領域をリモートメモリ６０２Ｃとして割り当てることをメモリデーモン８０３Ｃから要求されると、ステップＳ２で確保したメモリプールから当該メモリサイズのメモリブロックを切り出してこれを要求されたメモリ領域として割り当てる。そして、ステップＳ７で、メモリデバイスドライバ８０５Ｃは、割り当てたメモリ領域の物理アドレスを含むメモリ割り当て結果をメモリデーモン８０３に送る。
図２３は、リーフノード５０Ｂのメモリライブラリ８０２Ｂが上述のステップＳ１２，Ｓ１７，Ｓ１９で行う処理の詳細な手順を示すフローチャートである。上述のステップＳ１２では、メモリライブラリ８０２Ｂは、共有メモリＩＤを含むメモリアタッチ要求がユーザプログラム８０１Ｂから送られると、アタッチ対象のメモリが他のプロセッサノードのものか否か、即ち、当該共有メモリＩＤについてステータスが「使用中」であるとして共有メモリ管理テーブルに記憶されているか否かを判断する（ステップＳ５１）。当該判断結果が肯定的である場合、メモリライブラリ８０２Ｂは、共有メモリ管理テーブルに当該共有メモリＩＤと対応付けられて記憶されているリモートメモリ６０２Ｃの物理アドレスに対するメモリウィンドウ６０３Ｂへのマッピングを要求するメモリマッピング要求をルートノード５０Ａに対して送信する（ステップＳ５２）。
そして、上述のステップＳ１７では、メモリライブラリ８０２Ｂは、メモリマッピング結果をルートノード５０Ａから受け取ると、メモリデバイスドライバ８０５Ｂに対して、リモートメモリ６０２Ｃがマッピングされているメモリ領域のアドレスについて、メインメモリ５０１Ｂのメモリ空間へマッピングすることを要求する。
その後、上述のステップＳ１９では、メモリライブラリ８０２Ｂは、当該メモリマッピング要求に従ってメモリマッピングを行ったメモリデバイスドライバ８０５Ｂから、メモリ空間にマッピングしたアドレスを含むメモリマッピング結果を受け取ると、当該アドレスを含むメモリマッピング結果をユーザプログラム８０１Ｂに送る。尚、メモリライブラリ８０２Ｂは、当該アドレスの代わりに共有メモリＩＤを含むメモリマッピング結果をユーザプログラム８０１Ｂに送るようにしても良い。
尚、ステップＳ５１の判断結果が否定的である場合、アタッチ対象のメモリは、ローカルメモリである、即ち、リーフノード５０Ｂ自身の有するメインメモリ５０１Ｂに割り当てられたリモートメモリである。この場合、メモリライブラリ８０２Ｂは、メモリデバイスドライバ８０５Ｂに対して、メインメモリ５０１Ｂのメモリ領域のアドレスについて、メインメモリ５０１Ｂのメモリ空間へマッピングすることを要求する。
図２４は、ルートノード５０Ａのメモリデーモン８０３Ａが上述のステップＳ１３，Ｓ１６で行う処理の詳細な手順を示すフローチャートである。上述のステップＳ１３では、メモリデーモン８０３Ａは、メモリウィンドウ６０３Ｂに対するリモートメモリ６０２Ｃの物理アドレスのマッピングを要求するメモリマッピング要求をリーフノード５０Ｂから受信すると、当該要求に従って、要求元のリーフノード５０Ｂのメモリウィンドウ６０３Ｂに対して、要求先のリーフノード５０Ｃのリモートメモリ６０２Ｃの物理アドレスをマッピングする。そして、メモリデーモン８０３Ａは、メモリウィンドウ６０３Ｂのアドレスと、リモートメモリ６０２Ｃのアドレスとの対応関係をメモリウィンドウ管理テーブルに記憶する。次いで、メモリデーモン８０３Ａは、メモリマッパ管理デーモン８０６Ａに対して、マッピングコネクションの作成を要求する。
そして、上述のステップＳ１６では、メモリデーモン８０３Ａは、当該要求に従ってマッピングコネクションを作成する処理を行ったメモリマッパ管理デーモン８０６Ａからマッピングコネクション作成結果を受け取ると、リモートメモリ６０２Ｃをマッピングしたメモリウィンドウ６０３Ｂの物理アドレスを含むメモリマッピング結果をリーフノード５０Ｂに送信する。
図２５は、リーフノード５０Ｂのメモリデバイスドライバ８０５Ｂが上述のステップＳ１８で行う処理の詳細な手順を示すフローチャートである。メモリデバイスドライバ８０５Ｂは、リモートメモリ６０２Ｃがマッピングされているメモリ領域のアドレスについて、メモリ空間へマッピングすることをメモリデーモン８０３Ｂから要求されると、当該要求に従って、物理アドレス及びメモリサイズによって指定されるメモリ領域を当該プロセスのメモリ空間にマッピングする（ステップＳ６０）。このマッピングは、例えば、ＣＰＵ５００Ｂの有するＭＭＵのページテーブルを操作することにより行う。そして、メモリデバイスドライバ８０５Ｂは、メモリ領域をマッピングしたアドレスを含むメモリマッピング結果をメモリライブラリ８０２Ｂに送る（ステップＳ６１）。
次に、リーフノード５０Ｃが自身の有するリモートメモリ６０２Ｃにアクセスする場合の処理の手順について図２６を参照しながら説明する。この場合、リモートメモリ６０２Ｃは、ローカルメモリとして機能する。尚、上述の処理の手順と共通する部分についてはその説明を省略することがある。メモリデバイスドライバ８０５Ｃは、メインメモリ５０１Ｃにおいて物理アドレスが連続的となるようメモリ領域をメモリプールとして確保する（ステップＳ１００）。ユーザプログラム８０１Ｃが、共有メモリキー及びメモリサイズを含むメモリ割り当て要求をメモリライブラリ８０２Ｃに送ると（ステップＳ１０１）、メモリライブラリ８０２Ｃはこれをメモリデーモン８０３Ｃに送る（ステップＳ１０２）。メモリデーモン８０３Ｃは、共有メモリキーに対応して共有メモリＩＤ管理テーブルに記憶されているアドレスを取得し、このアドレスを含むメモリ割り当て結果をメモリライブラリ８０２Ｃに送る（ステップＳ１０３）。メモリライブラリ８０２Ｃは、メモリ割り当て結果を受け取ると、当該メモリ割り当て結果に含まれるアドレスに対応して共有メモリＩＤ管理テーブルに記憶されている共有メモリＩＤを含むメモリ割り当て結果をユーザプログラム８０１Ｃに送る（ステップＳ１０４）。ユーザプログラム８０１Ｃは、メモリ割り当て結果を受け取ると（ステップＳ１０５）、メモリライブラリ８０２Ｃに対して、当該メモリ割り当て結果に含まれる共有メモリＩＤを送ってメモリのアタッチを要求する（ステップＳ１０６）。メモリライブラリ８０２Ｃは、当該要求に従って、当該共有メモリＩＤに対応して共有メモリＩＤ管理テーブルに記憶されているアドレスを、メモリデバイスドライバ８０５Ｃに対して送ってメモリマッピングを要求する（ステップＳ１０７）。メモリデバイスドライバ８０５Ｃは、当該要求に従って、当該アドレスのメモリ領域について、メインメモリ５０１Ｃのメモリ空間へマッピングするメモリマッピングを行い、マッピングしたアドレスを含むメモリマッピング結果をメモリライブラリ８０２Ｃに送る(ステップＳ１０８)。メモリライブラリ８０２Ｃは、メモリマッピング結果に含まれるアドレスを含むメモリアタッチ結果をユーザプログラム８０１Ｃに送る(ステップＳ１０９)。ユーザプログラム８０１Ｃは、メモリアタッチ結果を受け取る（ステップＳ１１０）。
次に、リーフノード５０Ｃが自身の有するメインメモリ５０１Ｃに割り当てられたリモートメモリ６０２Ｃの利用を終了する処理の手順について図２７を参照しながら説明する。この場合、リモートメモリ６０２Ｃは、ローカルメモリとして機能する。尚、上述の処理の手順と共通する部分についてはその説明を省略することがある。リーフノード５０Ｃのユーザプログラム８０１Ｃは、共有メモリキーを含むメモリデタッチをメモリライブラリ８０２Ｃに対して要求し（ステップＳ１５０）、メモリライブラリ８０２Ｃは、メモリデバイスドライバ８０５Ｃに対してメモリアンマップを要求する（ステップＳ１５１）。尚、上述したように共有メモリキーに対応する共有メモリＩＤに対応して共有メモリＩＤ管理テーブルに記憶されているアドレスのリモートメモリがデタッチ対象及びアンマップ対象のメモリとなる。メモリデバイスドライバ８０５Ｃは、当該要求に応じて、メモリアンマップを行い、その結果を示すメモリアンマップ結果をメモリライブラリ８０２Ｃに対して送る（ステップＳ１５２）。メモリライブラリ８０２Ｃは、メモリアンマップ結果を受け取ると、共有メモリＩＤを含むメモリデタッチ結果をユーザプログラム８０１Ｃに対して送る（ステップＳ１５３）。ユーザプログラム８０１Ｃは、メモリデタッチ結果を受け取ると（ステップＳ１５４）、メモリライブラリ８０２Ｃに対して共有メモリＩＤを送ってメモリ解放を要求し（ステップＳ１５５）、メモリライブラリ８０２Ｃは、メモリデーモン８０３Ｃに対してメモリ解放を要求する（ステップＳ１５６）。メモリデーモン８０３Ｃは、当該要求に従って、当該共有メモリＩＤに対応付けられて共有メモリＩＤ管理テーブルに記憶される参照カウントを「１」デクリメントする。そして、メモリデーモン８０３Ｃは、メモリ解放結果をメモリライブラリ８０２Ｃに対して送り（ステップＳ１５７）、メモリライブラリ８０２Ｃは、メモリ解放結果をユーザプログラム８０１Ｃに対して送る（ステップＳ１５８）。ユーザプログラム８０１Ｃは、メモリ解放結果を受け取る（ステップＳ１５９）。この結果、リモートメモリ６０２Ｃの利用が終了する。
次に、リーフノード５０Ｂがリモートメモリ６０２Ｃを解放する処理の手順について説明する。図２８は、リーフノード５０Ｂがリモートメモリ６０２Ｃを解放する処理の手順を示すシーケンスチャートである。尚、上述の処理の手順と共通する部分についてはその説明を省略することがある。ユーザプログラム８０１Ｂは、メモリライブラリ８０２Ｂに対して共有メモリキーを送りメモリデタッチを要求し（ステップＳ２００）、メモリライブラリ８０２Ｂは、メモリデバイスドライバ８０５Ｂに対してメモリアンマップを要求する（ステップＳ２０１）。尚、上述したように共有メモリキーに対応する共有メモリＩＤに対応して共有メモリＩＤ管理テーブルに記憶されているアドレスのリモートメモリがデタッチ対象及びアンマップ対象のメモリとなる。メモリデバイスドライバ８０５Ｂは、当該要求に応じて、メモリアンマップを行い、その結果を示すメモリアンマップ結果をメモリライブラリ８０２Ｂに対して送る（ステップＳ２０２）。メモリライブラリ８０２Ｂは、メモリアンマップ結果を受け取ると、共有メモリＩＤを含むメモリアンマップ要求をルートノード５０Ａに対して送信する（ステップＳ２０３）。
ルートノード５０Ａのメモリデーモン８０３Ａは、メモリアンマップ要求を受信すると、メモリマッパ管理デーモン８０６Ａに対して、共有メモリＩＤを送ってマッピングコネクションの削除を要求する（ステップＳ２０４）。メモリマッパ管理デーモン８０６Ａは、当該要求に従って、マッピングコネクションを削除し、その結果を示し共有メモリＩＤを含むコネクション削除結果をメモリデーモン８０３Ａに送る（ステップＳ２０５）。メモリデーモン８０３Ａは、コネクション削除結果を受け取ると、共有メモリＩＤを含むメモリアンマップ結果をリーフノード５０Ｂに送信する（ステップＳ２０６）。
リーフノード５０Ｂのメモリライブラリ８０２Ｂは、メモリアンマップ結果を受信すると、共有メモリＩＤを含むメモリデタッチ結果をユーザプログラム８０１Ｂに送る（ステップＳ２０７）。ユーザプログラム８０１Ｂは、メモリデタッチ結果を受け取ると（ステップＳ２０８）、共有メモリＩＤを含むメモリ解放要求をメモリライブラリ８０２Ｂに送る（ステップＳ２０９）。メモリライブラリ８０２Ｂは、共有メモリＩＤを含むメモリ解放要求をリーフノード５０Ｃに対して送信する（ステップＳ２１０）。
リーフノード５０Ｃのメモリデーモン８０３Ｃは、共有メモリＩＤを含むメモリ解放要求を受け取ると、当該共有メモリＩＤに対応してメモリウィンドウ管理テーブルの参照カウントを「１」デクリメントし、メモリデバイスドライバ８０５Ｃに対して共有メモリＩＤを送ってメモリの解放を要求する（ステップＳ２１１）。メモリデバイスドライバ８０５Ｃは、当該要求に従って、共有メモリＩＤに対応するリモートメモリ（ここでは、リモートメモリ６０２Ｃである）を解放し、その結果を示すメモリ解放結果をメモリデーモン８０３に送る（ステップＳ２１２）。メモリデーモン８０３Ｃは、メモリ解放結果をリーフノード５０Ｂに送信する（ステップＳ２１３）。
リーフノード５０Ｂのメモリライブラリ８０２Ｂは、メモリ解放結果を受信すると、ユーザプログラム８０１Ｂに対してメモリ解放結果を送る（ステップＳ２１４）。ユーザプログラム８０１Ｂは、メモリ解放結果を受け取る（ステップＳ２１５）。この結果、リモートメモリ６０２Ｃは解放される。
次に、図２８に示した処理のうち、メモリライブラリ８０２Ｂと、メモリデーモン８０３Ａ，８０３Ｃと、メモリデバイスドライバ８０５Ｂ，８０５Ｃとが各々行う処理の手順について詳細に説明する。
図２９は、リーフノード５０Ｂのメモリライブラリ８０２Ｂが上述のステップＳ２０１，Ｓ２０３で行う処理の詳細な手順を示すフローチャートである。上述のステップＳ２０１では、メモリライブラリ８０２Ｂは、メモリデタッチ要求がユーザプログラム８０１Ｂから送られると、デタッチ対象のメモリが他のプロセッサノードのものか否か、即ち、当該共有メモリＩＤについてステータスが「使用中」であるとして共有メモリ管理テーブルに記憶されているか否かを判断する（ステップＳ２３０）。当該判断結果が肯定的である場合、メモリライブラリ８０２Ｂは、リモートメモリ６０２Ｃがマッピングされているメモリ領域のアドレスについて、メインメモリ５０１Ｂのメモリ空間へのマッピングを解除（メモリアンマップ）をメモリデバイスドライバ８０５Ｂに対して要求する（ステップＳ２３１）。
そして、上述のステップＳ２０３では、メモリライブラリ８０２Ｂは、当該メモリアンマップ要求に従ってメモリアンマップを行ったメモリデバイスドライバ８０５Ｂからメモリアンマップ結果を受け取ると、ルートノード５０Ａに対して、リモートメモリ６０２Ｃに対するメモリウィンドウ６０３Ｂへのマッピングの解除を要求するメモリアンマップ要求を送信する。
尚、ステップＳ２３０の判断結果が否定的である場合、デタッチ対象のメモリは、ローカルメモリである、即ち、リーフノード５０Ｂ自身の有するメインメモリ５０１Ｂに割り当てられたリモートメモリである。この場合、メモリライブラリ８０２Ｂは、メモリデバイスドライバ８０５Ｂに対して、メインメモリ５０１Ｂのメモリ領域のアドレスについて、メインメモリ５０１Ｂのメモリ空間へのマッピングの解除を要求する。
図３０は、リーフノード５０Ｂのメモリデバイスドライバ８０５Ｂが上述のステップＳ２０２で行う処理の詳細な手順を示すフローチャートである。メモリデバイスドライバ８０５Ｂは、メモリアンマップをメモリデーモン８０３Ｂから要求されると、リモートメモリ６０２Ｃがマッピングされているメモリ領域のアドレスについて、メインメモリ５０１Ｂのメモリ空間へのマッピングを解除する。
図３１は、ルートノード５０Ａのメモリデーモン８０３Ａが上述のステップＳ２０５で行う処理の詳細な手順を示すフローチャートである。メモリデーモン８０３Ａは、メモリアンマップ要求をリーフノード５０Ｂから受信すると、メモリウィンドウ６０３Ｂに対するリモートメモリ６０２Ｃのマッピングを解除する。
図３２は、リーフノード５０Ｂのメモリライブラリ８０２Ｂが上述のステップＳ２１０で行う処理の詳細な手順を示すフローチャートである。メモリライブラリ８０２Ｂは、ユーザプログラム８０１Ｂからメモリ解放要求を受け取ると、当該メモリ解放要求に含まれる共有メモリＩＤを用いて、解放対象のリモートメモリを有するプロセッサノードを検索する（ステップＳ２４０）。具体的には、メモリライブラリ８０２Ｂは、当該共有メモリＩＤに対応して共有メモリＩＤ管理テーブルに記憶されているリモートノードＩＤを参照し、当該リモートノードＩＤによって対象のプロセッサノードを特定する。そして、メモリライブラリ８０２Ｂは、特定したプロセッサノード（ここでは、プロセッサノード５０Ｃである）に対して、共有メモリＩＤを含むメモリ解放要求を送信する（ステップＳ２４１）。
図３３は、リーフノード５０Ｃのメモリデーモン８０３Ｃが上述のステップＳ２１１で行う処理の詳細な手順を示すフローチャートである。メモリデーモン８０３Ｃは、共有メモリＩＤを含むメモリ解放要求をリーフノード５０Ｂから受信すると、当該共有メモリＩＤに対応付けられて共有メモリＩＤ管理テーブルに記憶される参照カウントを「１」デクリメントする（ステップＳ２５０）。次いで、メモリデーモン８０３Ｃは、当該参照カウントが「０」であるか否かを判断し（ステップＳ２５１）、当該判断結果が肯定的である場合、メモリデバイスドライバ８０５Ｃに対して、共有メモリＩＤに対応するアドレスを送ってメモリの解放を要求する（ステップＳ２５２）。ステップＳ２５０の判断結果が否定的である場合は、リーフノード５０Ｃにおいてリモートメモリ６０２Ｃの利用を終了する場合である。この場合、メモリデーモン８０３Ｃは、上述した図の２７のステップＳ１５７で、メモリ解放結果をメモリライブラリ８０２Ｃに送る。
図３４は、リーフノード５０Ｃのメモリデバイスドライバ８０５Ｃが上述のステップＳ２１２で行う処理の詳細な手順を示すフローチャートである。メモリデバイスドライバ８０５Ｃは、メモリデーモン８０３Ｃからアドレスを受け取りメモリの解放が要求されると、当該アドレスで指定されたメモリブロックをメモリプールに返却する。そして、メモリデバイスドライバ８０５Ｃは、メモリ解放結果をメモリデーモン８０３Ｃに送る。
次に、以上のようにしてメモリウィンドウに対してリモートメモリがマッピングされた後、リモートメモリに対してＣＰＵ５００が読み出し又は書き込みする処理の手順について説明する。図３５は、プロセッサノード５０ＢのＣＰＵ５００Ｂがプロセッサノード５０Ｃのリモートメモリ６０２Ｃに対して読み出しする処理の手順を簡略的に示すタイミングチャートである。
プロセッサノード５０ＢのＣＰＵ５００Ｂが、リモートメモリ６０２Ｃに記憶されているデータを取得すべく、リモートメモリ６０２Ｃのアドレスを指定して、データの読み出しを要求するメモリリード要求をメモリマッピングカード５０５Ｂに対して送る（ＳＴ５０）。ＣＰＵ５００Ｂはメモリリードのリード結果が返ってくるまで待機する。メモリマッピングカード５０５Ｂは、メモリリード要求に従って、プロセッサノード５０Ｃのメモリマッピングカード５０５Ｃに対してリモートメモリ６０２Ｃのアドレスを指定して読み出し要求を送信する（ＳＴ５１）。メモリマッピングカード５０５Ｃは、指定されたアドレスに記憶されているデータをメインメモリ５０１Ｃにあるリモートメモリ６０２Ｃから読み出し（ＳＴ５２）、これをリード結果として取得し（ＳＴ５３）、これをマッピングした後、マッピングしたアドレスを含む読み出し要求を、リーフノード５０Ｂのメモリマッピングカード５０５Ｂに対して送信する（ＳＴ５４）。メモリマッピングカード５０５Ｃは、読み出し要求を受信すると、マッピングされたデータを読み出し、このデータをリード結果としてＣＰＵ５００Ｂに送る（ＳＴ５５）。ＣＰＵ５００Ｂは、リード結果を受け取ると、新たにデータを取得すべく、リモートメモリ６０２Ｃのアドレスを指定してメモリリード要求をメモリマッピングカード５０５Ｂに対して送る（ＳＴ５６）。以降のタイミングＳＴ５７〜Ｓ６０については、上述のタイミングＳＴ５１〜ＳＴ５５と同様である。
以上のようにして、プロセッサノード５０ＢのＣＰＵ５００Ｂはリモートメモリ６０２Ｃに対するリード結果を得る。尚、ＣＰＵ５００Ｂはリモートメモリ６０２Ｃに対してメモリリードを連続的に行おうとしても、プロセッサノード５０Ｂ〜５０Ｃ間の往復のレイテンシ以下の間隔でメモリリードを繰り返すことができない。このため、データの読み出し時のパフォーマンス（メモリバンド幅：単位時間当たりにどれだけのデータにアクセスすることができるかどうか。単位は MB/s等。）は低下してしまう。
図３６は、プロセッサノード５０ＢのＣＰＵ５００Ｂがプロセッサノード５０Ｃのリモートメモリ６０２Ｃに対して書き込みする処理の手順を簡略的に示すタイミングチャートである。プロセッサノード５０ＢのＣＰＵ５００Ｂが、リモートメモリ６０２Ｃにデータを書き込むべく、リモートメモリ６０２Ｃのアドレスを指定して書き込み対象のデータと共に当該データの書き込みを要求するメモリライト要求をメモリマッピングカード５０５Ｂに対して送る（ＳＴ８０）。メモリマッピングカード５０５Ｂは、メモリライト要求に従って、プロセッサノード５０Ｃのメモリマッピングカード５０５Ｃに対してアドレスを指定して書き込み対象のデータと共に書き込み要求を送信する（ＳＴ８１）。メモリマッピングカード５０５Ｃは、指定されたアドレスに書き込み対象のデータをメインメモリ５０１Ｃにあるリモートメモリ６０２Ｃに書き込む（ＳＴ８２）。
ここでは、ＣＰＵ５００Ｂは、プロセッサノード５０Ｂでのメモリライト結果を待機せず、次に書き込み対象のデータがあれば、同様にして、メモリライト要求を送る（ＳＴ９０）。以降のタイミングＳＴ９１〜ＳＴ９２は上述のタイミングＳＴ８１〜ＳＴ８２と同様である。即ち、ＣＰＵ５００Ｂはデータの書き込み動作を連続して繰り返すことができる。このため、原理的にメモリライト時のパフォーマンスはデータの読み出しを行った場合よりも高くなる。
次に、リーフノード５０Ｂとリーフノード５０Ｃとが互いの有するリモートメモリを介して双方向に大量のデータをやり取りする例について説明する。ここでは、リーフノード５０Ｂについても、リーフノード５０Ｃと同様にして、メインメモリ５０１Ｂにリモートメモリ６０２Ｂを有するものとする。図３７は、リーフノード５０Ｂとリーフノード５０Ｃとで各々動作するプロセス間で双方向に大量のデータをやり取りする場合のデータフローを示す図である。この例ではプロセッサノード５０Ｂで動作しているプロセス７００Ｂからプロセッサノード５０Ｃで動作しているプロセス７００Ｃに対して何らかの処理を依頼し、プロセス７００Ｃは処理した結果をプロセス７００Ｂに返している。なお処理を依頼する際と処理結果を返す際とには大量のデータを受け渡す必要があるものとする。
まずプロセス７００Ｂは、処理対象のデータをプロセッサノード５０Ｃのメインメモリ５０１Ｃにあるリモートメモリ６０２Ｃに書き込み（ＳＴ１００）、上述したソケット通信を利用してプロセス７００Ｃに対して処理を行うことを要求する。プロセス７００Ｃは、リモートメモリ６０２Ｃから処理対象のデータを読み出し（ＳＴ１０１）、処理要求に従った処理を行い、処理した結果をプロセッサノード５０Ｂのメインメモリ５０１Ｂにあるリモートメモリ６０２Ｂに書き込む（ＳＴ１０２）。そして処理が完了したらプロセス７００Ｃはソケット通信を利用してプロセス７００Ｂに対して処理の完了を通知する。プロセス７００Ｂはリモートメモリ６０２Ｂから処理結果を読み出す（ＳＴ１０３）。
次に、図１９のステップＳ２に関して図３８を参照しながら説明する。図３８は、リーフノード５０Ｃのメモリデバイスドライバ８０５Ｃがリモートメモリ６０２Ｃのためのメモリ領域を物理アドレスが連続的となるようメモリプールとして確保した状態を例示する図である。同図では、メインメモリ５０１Ｃのメモリ空間６００Ｃにおいて、リモートメモリ６０２Ｃのメモリ領域（メモリページ）について、物理アドレスが連続的に確保された状態が示されている。ＯＳ８０４Ｃの起動時や起動直後であれば、メモリのフラグメンテーションはそれほど進んでいないため、このように物理アドレスが連続しているメモリ領域を確保することは容易である。このため、上述のステップＳ２では、ＯＳ８０４Ｃの起動時にリモートメモリ６０２Ｃとして必要な大きさのメモリ領域を予め確保しておく。このことにより、後にリーフノード５０Ｂからリモートメモリ６０２Ｃに対するメモリ割り当て要求を受信した場合に、確保済みのメモリ領域から要求されたメモリサイズのメモリ領域を切り出すことによって、物理アドレスが連続しているメモリ領域を常に確保できることを保証している。尚、図１９のステップＳ１においてリーフノード５０Ｂがメインメモリ５０１Ｂのメモリ空間６００Ｂにおいて、リーフノード５０Ｂ自身のリモートメモリのためのメモリ領域を確保するのも同様の理由である。
図３９はＯＳ８０４が管理しているメモリ空間６００において空きメモリの物理アドレスが断片化された状態を示す図である。ＯＳ８０４が起動してから時間が経過するにつれて、空きメモリの物理アドレスの分断化（フラグメンテーション）が発生してくる。このようにメモリのフラグメンテーションが進んでしまった場合であっても、ＣＰＵ５００の有するＭＭＵにより実現されるページング機能により、プロセスが動作する仮想メモリ空間に対して空きメモリをページ単位で任意のアドレスにマッピングすることができるため、プロセスを動作させるという点では全く支障が生じない。但し、メモリマッピングカード５０５を介してアクセスするリモートメモリ６０２については物理アドレスでアクセス先を指定する必要があるため、ページサイズを越える大きさのメモリサイズのメモリ領域をリモートメモリとして確保する場合には、物理アドレスが連続しているメモリ領域が必要となる。しかし図３９に示した状態のように、空きメモリの分断化が進んでいると、物理アドレスが連続しているメモリ領域を確保することができない。このため、上述した図３８の例を用いて説明したように、ＯＳ８０４の起動時に、リモートメモリとして必要な大きさのメモリ領域をメモリ空間６００において予め確保しておくのである。
一方、リモートメモリ６０２がマッピングされるメモリウィンドウ６０３は、まとめ書き可能領域として設定することが望ましい。図４０はメモリウィンドウ６０３をまとめ書き可能領域として設定した場合に、ＣＰＵ５００がメモリウィンドウ６０３に対して連続的に書き込みを行った時のバスサイクルの様子を示す図である。この場合にはＣＰＵ５００はバースト転送サイクルを発行することになる。例えば、バースト長が「４」である場合、ＣＰＵ５００は、開始アドレス１つに対して、４つのデータをまとめて転送するというサイクルを繰り返す。このため、リモートメモリ６０２に対する書き込みのパフォーマンスは非常に向上することになる。
つまり、プログラムがリモートメモリ６０２に対してデータを書き込んだ場合に、その都度ＰＣＩバスに対してメモリ書き込みサイクルが発行されることがなく、ある程度の個数の書き込み要求がライトバッファにたまった時にＰＣＩバスに対してバースト転送でのメモリ書き込みサイクルが発行されるため、バス帯域の利用効率がシングル転送時に比べると劇的に改善され、リモートメモリ６０２に対して書き込みを行った場合のパフォーマンスも非常に良好なものとなる。
もし、メモリウィンドウ６０３をまとめ書き不可領域として設定した場合には、書き込みのパフォーマンスは非常に低下してしまう。図４１はメモリウィンドウ６０３をまとめ書き不可領域として設定した場合に、ＣＰＵ５００がメモリウィンドウ６０３に対して連続的に書き込みを行った時のバスサイクルの様子を示す図である。この場合にはＣＰＵ５００はシングル転送サイクルを繰り返すことになる。即ち、ＣＰＵ５００は、開始アドレス１つに対して、１つのデータを転送するというサイクルを繰り返す。このため、ＰＣＩバスではバス帯域の利用効率が極端に低下してしまい、この結果、リモートメモリ６０２に対する書き込みのパフォーマンスは非常に低下してしまうのである。
以上のように、上述した実施の形態においては、リモートメモリのメモリマッピングに関するアクセスで発生する通信トラフィックとプロセス間通信によるトラフィックとが各々別個の通信回線５１，５２を流れるように構成したため、リモートメモリに対して大量のデータの読み書きを行ったような場合であっても、プロセス間通信のレイテンシには影響が無く、マルチプロセッサシステム全体の処理効率が低下してしまうことを防止することができる。
また、一つのプロセッサノード（ルートノード）が代表してマルチプロセッサシステムにおいて行われるメモリマッピングを一元管理するように構成したため、プロセスがリモートメモリのマッピング状態を設定したり変更しようとした場合には、ルートノードに対してメモリマッピング要求を送信すれば良い。メモリマッピング要求の要求元のプロセッサノードと要求先のプロセッサノードとはクライアント・サーバの関係を結ぶ必要があるが、もしプロセッサノードの数が「ｎ」だとすると、クライアント・サーバ関係の全組み合わせ数は「Ｏ（ｎ）」のオーダとなる。従って、プロセッサノードの数が増えたとしてもメモリ消費量はあまり増加しないため、コストパフォーマンスの良いマルチプロセッサシステムを提供することができる。
尚、従来のように、各プロセッサノードが自身の有するリモートメモリのメモリマッピング手段を管理する場合、プロセッサノードで動作するプロセスがリモートメモリのマッピング状態を設定したり変更したりする際には、対象となるメモリマッピング手段を管理しているプロセッサノードに対してメモリマッピング要求を送信する必要がある。この場合、プロセッサノードの数が「ｎ」だとすると、メモリマッピング要求の要求元のプロセッサノードと要求先のプロセッサノードとが結ぶクライアント・サーバ関係の全組み合わせ数は、「Ｏ（ｎ２）」のオーダとなる。このため、ノード数が増えるにつれてクライアント・サーバ関係の組み合わせ数が爆発的に増加してしまう。クライアント・サーバの関係を結ぶためには相互の通信路、例えばソケット等を確保する必要がある。このため、クライアント・サーバ関係の組み合わせ数が増加するとそれに応じてメモリの消費量が増加してしまい、ひいてはコストアップにつながってしまうという不具合があった。しかし、上述したように、本実施の形態においては、このような不具合を抑制することができる。
また、プロセッサノード間の通信回線としてEthernet(登録商標）等のTCP/IP通信が可能なネットワーク通信手段を採用しているため、UNIX(登録商標）-OSで最も一般的に用いられているプロセス間通信手段であるソケット通信を利用することができる。よって一般的なオープンソースや既存のソフトウェア資産を利用することが容易となり、ソフトウェア開発効率の向上やソフトウェア開発費の低減を期待することができる。
また、ＣＰＵがメモリマッピングカードを介してリモートメモリに対して大量のデータを書き込んだ場合に、ＰＣＩバスやPCI-Express等の汎用バスに対してバースト転送サイクルが発行されるため、汎用バスの利用効率を向上させることができる。従来では、このような場合にバースト転送サイクルが発行されなかったため、汎用バスの利用効率が低下してしまい、リモートメモリに対する書き込み時のパフォーマンスが汎用バスの理論性能の1/１０以下に落ち込んでしまう恐れがあった。しかし、本実施の形態においては、リモートメモリに対する書き込み時のパフォーマンスが汎用バスの理論性能に近いレベルに維持されるため、コストパフォーマンスの良いマルチプロセッサシステムを提供することができる。
また、プロセッサノード間で双方向にデータ通信するのに送信及び受信別々のメモリバッファを利用しリモートメモリに対しては常に書き込みを行うように構成しているため、リモートメモリに対する読み出し時に発生する通信レイテンシの影響を受けることを防ぐことができる。そのためプロセッサノード間で双方向にデータ転送を行った場合であっても、効率良くプロセッサノード間通信を行うことができるため、コストパフォーマンスの良いマルチプロセッサシステムを提供することができる。
また、プロセッサノード間で大量のデータを通信する際には、データ送信元のプロセッサノードで動作するプロセスが、他のプロセッサノードにメモリ領域の確保を要求することによって、リモートメモリのメモリ領域を確保し、送信対象のデータをメモリマッピングカードを介して他のプロセッサノード上のリモートメモリに書き込み、データ受信先となる当該他のプロセッサノードで動作するプロセスが自身の確保したリモートメモリからデータの読み出しを行うことができる。リモートメモリに対する読み出し動作は書き込み動作と比べると非常に高速であるため、データ転送の処理効率が向上し、コストパフォーマンスの良いマルチプロセッサシステムを提供することができる。
また、メモリマッピングカードを介してプロセッサノード間で大量のデータの通信を行うのに、UNIX(登録商標）-OSで一般的に用いられている共有メモリ・プログラミングモデルが利用できる。このため、独自のAPIセットを利用する必要なく、オープンソースや既存のソフトウェア資産を利用することが容易となる。従って、ソフトウェア開発効率の向上やソフトウェア開発費の低減を期待することができる。
また、ＯＳの起動時にプロセッサノード間でのデータ転送用として物理アドレスが連続しているメモリ領域を確保するため、仮にＯＳが管理している空きメモリの分断化が進んでいたとしても、物理アドレスが連続している確保済みのメモリ領域を使用することができる。このため、プロセッサノード間でデータ転送を行うことを保証でき、信頼性の高いマルチプロセッサシステムを提供することができる。
[変形例]
また、上述した各実施の形態に限定されるものではなく、以下に例示するような種々の変形が可能である。
＜変形例１＞
上述した実施の形態において、本実施形態のプロセッサノードで実行される各種プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。また、当該プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。
＜変形例２＞
上述した実施の形態において、プロセッサノード５０は、Ethernet(登録商標）カード５０４を有するように構成したが、この代わりに、仮想ネットワーク機能を有する仮想Ethernet(登録商標）ドライバを備えるように構成しても良い。仮想Ethernet(登録商標）ドライバは、例えば、ハードウェアではなく、ソフトウェアにより構成する。仮想Ethernet(登録商標）ドライバは実際の通信手段としては、リモートメモリのメモリマッピングに関するデータを通信する通信手段として機能しながら、Ethernet(登録商標）デバイスの機能をエミュレーションすることにより、上位のレイヤーに対しては本物のEthernet(登録商標）デバイスと同等の機能を提供するモジュールである。この仮想Ethernet(登録商標）ドライバ上でTCP/IP通信を行うことにより、プロセスは任意のプロセッサノード間でソケット通信を行うことが可能となる。このような構成によれば、物理的に通信回線５１を設ける必要がなく、通信に用いるケーブルだけでなく、コネクタ、トランスミッタ、レシーバ、通信インターフェイスチップ等を全て二重に用意する必要がないため、コストパフォーマンスの良いマルチプロセッサシステムを提供することができる。
＜変形例３＞
上述した実施の形態において、各プロセッサノードは、ライトバッファをメモリコントローラ又はＣＰＵに設けるように構成しても良い。図４２は、ライトバッファ５０８をメモリコントローラ５０２´に設けたプロセッサノード５０´の構成を例示する図である。ライトバッファ５０８は、ＣＰＵ５００からＰＣＩデバイスに対する書き込み要求を保持する何段かのバッファで構成されており、ライトバッファ５０８内にたまっている書き込み要求のライトアドレスを比較し、ライトアドレスが連続的なアドレスである場合にはバースト転送サイクルをホスト−ＰＣＩブリッジ５０３に対して発行する機能を有している。
図４３は、ライトバッファ５０８をＣＰＵ５００´に設けたプロセッサノード５０"の構成を例示する図である。ＣＰＵ５００´は、メインメモリ５０１やＩ／Ｏデバイスに対する書き込み要求をバッファリングする機能を備えており、ＣＰＵ５００´内の特定のレジスタに所定の設定値を書き込むことにより、ライトバッファ５０８を有効にして、連続的なライトアドレスについてバースト転送サイクルをホスト−ＰＣＩブリッジ５０３に対して発行する機能を実現させる。
＜変形例４＞
上述した実施の形態において、プロセッサノード５０は、キャッシュメモリを備えるように構成しても良く、この場合、メモリウィンドウ６０３に対してキャッシュメモリを無効にするようにしても良い。図４４は、プロセッサノード５０Ｂがキャッシュメモリ９００Ｂを有し、プロセッサノード５０Ｃがキャッシュメモリ９００Ｃを有し、各メモリウィンドウ６０３Ｂ〜６０３Ｃに対してキャッシュメモリ９００Ｂ〜９００Ｃを無効にした場合の動作を概念的に例示した図である。ここでまずプロセッサノード５０ＢのＣＰＵ５００Ｂがリモートメモリ６０２Ｃがマッピングされているメモリウィンドウ６０３Ｂを通してプロセッサノード５０Ｃ上のメインメモリ５０１Ｃにあるリモートメモリ６０２Ｃのアドレスに対してデータを書き込む（ＳＴ１１０）。このデータに従ってプロセッサノード５０ＣのＣＰＵ５００Ｃが処理を行いリモートメモリ６０２Ｃに処理結果のデータを書き込む（ＳＴ１１１）。そして、プロセッサノード５０ＢのＣＰＵ５００Ｂは、リモートメモリ６０２Ｃに書き込まれたデータを読み出す（ＳＴ１１２）。この場合にはリモートメモリ６０２Ｃに記憶されたデータのコピーがキャッシュメモリ９００Ｃに保持されることがない。
このため、実装のためには多大なコストのかかるキャッシュコヒーレンシ維持機構が無いような場合であっても、キャッシュのコヒーレンシの維持が保証されることになる。また、複数のプロセッサノードがリモートメモリを共用した場合であっても、キャッシュコヒーレンシの維持が保持される。このため、複数のプロセッサノードにおいても各々キャッシュコヒーレンシ維持機構を備えずに済むため、コストダウンが可能になる。さらにキャッシュコヒーレンシを維持するためのＣＰＵ間のトラフィックが不要のため、マルチプロセッサシステム内のＣＰＵの個数を増やしていけば、マルチプロセッサシステム全体のパフォーマンスをリニアに向上させることができる。よってコストパフォーマンスの良いマルチプロセッサシステムを提供することができる。
このようにするのは、メモリウィンドウ６０３に対してキャッシュメモリ９００を有効にした場合には以下のような問題が生じる恐れがあるからである。図４５は各メモリウィンドウ６０３Ｂ〜６０３Ｃに対してキャッシュメモリ９００Ｂ〜９００Ｃを有効にした動作を概念的に例示した図である。この場合、プロセッサノード５０ＢのＣＰＵ５００Ｂがメモリウィンドウ６０３Ｂを通してリモートメモリ６０２Ｃのアドレスに対してデータを書き込む（ＳＴ１１０）と、キャッシュメモリ９００が有効のため、書き込まれたデータは、キャッシュメモリ９００Ｂ内にも保持されることになる。次にプロセッサノード５０ＣのＣＰＵ５００Ｃが、さきほどＣＰＵ５００Ｂが書き込んだアドレスと同じアドレスに対して処理結果のデータを書き込んだ場合（ＳＴ１１１）、キャッシュのコヒーレンシを維持するための機構が無い場合には、当該処理結果のデータがキャッシュメモリ９００Ｂに反映されることは無いし、またキャッシュメモリ９００Ｂに保持されている古いデータが無効化されることもない。そして、ＣＰＵ５００Ｂがリモートメモリ６０２Ｃの同じアドレスに対してデータを読み出す場合には（ＳＴ１１２）、キャッシュメモリ９００Ｂからデータを読み出すため、ＣＰＵ５００Ｂはリモートメモリ６０２Ｃに実際に書き込まれているデータ、即ち、ＣＰＵ５００Ｃが書き込んだ処理結果のデータではなく、上述のタイミングＳＴ１１０でキャッシュメモリ９００Ｂ内に保持された古いデータを得ることになる。このようにリモートメモリ６０２に対してキャッシュメモリ９００を有効にすることは、キャッシュのコヒーレンシが保たれる保証が無いため、場合によってはＣＰＵ５００がキャッシュメモリ９００から不正なデータを読み出すことによって、結果的にマルチプロセッサシステムとしての誤動作につながってしまうという問題が生じる恐れがある。
つまり、密結合型マルチプロセッサシステムでは、プロセッサノードに唯一存在しているメインメモリを複数のプロセッサノードで共用していたため、必然的に、共有メモリとして共用されるメインメモリ上にはプログラムコードとデータとの両方が格納される。メインメモリはＣＰＵのクロックスピードからするととても遅いデバイスである。このため、通常はＣＰＵの内外にキャッシュメモリを備え、メインメモリに対して行うデータの読み出し又は書き込みがキャッシュメモリにおいてヒットしている限りはメインメモリに対してアクセスしないようにすることで、ＣＰＵのパフォーマンスを維持するように構成されている。しかしキャッシュメモリを備えることで問題になるのが、そのデータの内容の整合性（コヒーレンシ）の維持である。例えば、図４５で説明したように、上述のタイミングＳＴ１１２でＣＰＵ５００Ｃがキャッシュメモリ９００Ｂ内に保持された古いデータを得る場合、キャッシュコヒーレンシが維持されないという不具合が生じることになる。通常はこのような不具合が生じることのないように、ＣＰＵは他のプロセッサのノードの有するＣＰＵが発行するバスサイクルを監視したり、あるいはＣＰＵ間でキャッシュの制御情報をやり取りすることにより、キャッシュメモリ内の古いデータを無効化する等の動作を行ってキャッシュコヒーレンシを維持している。このキャッシュコヒーレンシを維持する場合には、二つの問題点が発生する恐れがある。一つはこのキャッシュコヒーレンシを維持する機能を実現するためには複雑な制御回路が必要になってしまうため、もしキャッシュコヒーレンシ維持機構をＣＰＵ内に実装したとすればＣＰＵのコストアップにつながってしまうことである。もう一つは、マルチプロセッサシステム内のＣＰＵの個数を増やそうとするとキャッシュコヒーレンシを維持するためにＣＰＵ間でやり取りする通信トラフィックが無視できないほどに増大してしまうため、マルチプロセッサシステム全体のパフォーマンスが頭打ちになってしまうことである。しかしだからといって、メインメモリに対してキャッシュメモリを無効にしてしまうと、プログラムの実行に伴ってメモリアクセスの頻度が最も高いプログラムコードをフェッチするのにいちいちメインメモリにアクセスすることになってしまうため、ＣＰＵのパフォーマンスが劇的に低下してしまう恐れがある。このため、上述の図４４の例のように、メインメモリに対してキャッシュメモリを全く無効にするのではなく、メモリウィンドウに対してキャッシュメモリを無効にすることにより、ＣＰＵのパフォーマンスを低下させることなく、また、キャッシュコヒーレンシ維持機構が無いような場合であっても、キャッシュのコヒーレンシの維持を補償することができる。
本実施の形態にかかる共有メモリ型のマルチプロセッサシステムの構成を示す図である。 同実施の形態にかかるプロセッサノード５０Ａ〜５０Ｃの具体的なハードウェア構成を示す図である。 同実施の形態にかかるプロセッサノード５０を構成するハードウェアとメモリ空間との対応関係を示す図である。 同実施の形態にかかるリーフノード５０Ｂのソフトウェア構成を例示する図である。 同実施の形態にかかる共有メモリＩＤ管理テーブルのデータ構成を例示する図である。 同実施の形態にかかる連続物理メモリ管理テーブルのデータ構成を例示する図である。 同実施の形態にかかる連続物理メモリ管理テーブルのデータ構成を例示する図である。 同実施の形態にかかるルートノード５０Ａのソフトウェア構成を例示する図である。 同実施の形態にかかるメモリウィンドウ管理テーブルのデータ構成を例示する図である。 同実施の形態にかかるメモリウィンドウ管理テーブルのデータ構成を例示する図である。 同実施の形態にかかるマルチプロセッサシステムＳＹＭにおいて、メモリマッピングを行いリモートメモリへアクセスする処理の手順を概念的に示す図である。 同実施の形態にかかるマッピングが行われたリモートメモリ６０２Ｃに対してリーフノード５０Ｂがアクセスする場合の様子を例示する図である。 同実施の形態にかかるリーフノード５０Ｂがリーフノード５０Ｃの有するメインメモリ５０１のリモートメモリ６０２Ｃに対して書き込みを行った場合のデータフローを例示する図である。 同実施の形態にかかるリーフノード５０Ｂ〜５０Ｃ間でプロセスがソケットを利用して通信している様子を示す図である。 同実施の形態にかかるソケット通信時のデータフローを示す図である。 同実施の形態にかかるリーフノード５０Ｂが、リーフノード５０Ｃに対してリモートメモリ６０２Ｃのメモリ割り当てを要求する際の様子を示す図である。 同実施の形態にかかるルートノード５０Ａがリーフノード５０Ｂからの要求に応じてメモリウィンドウ６０３Ｂに対してリモートメモリ６０２Ｃのメモリマッピングを要求する際の様子を例示する図である。 同実施の形態にかかるプロセッサノード５０Ｃのメインメモリ５０１Ｃの一部であるリモートメモリ６０２Ｃが、プロセッサノード５０Ｂのメモリウィンドウ６０３Ｂにマッピングされた状態を例示する図である。 同実施の形態にかかるリーフノード５０Ｂがリーフノード５０Ｃのリモートメモリ６０２Ｃにアクセスする場合のシーケンスチャートである。 同実施の形態にかかるリーフノード５０Ｂのメモリライブラリ８０２Ｂが上述のステップＳ４，Ｓ９で行う処理の詳細な手順を示すフローチャートである。 同実施の形態にかかるリーフノード５０Ｃのメモリデーモン８０３Ｃが上述のステップＳ５，Ｓ８で行う処理の詳細な手順を示すフローチャートである。 同実施の形態にかかるリーフノード５０Ｃのメモリデバイスドライバ８０５ＣがステップＳ６，Ｓ７で行う処理の詳細な手順を示すフローチャートである。 同実施の形態にかかるリーフノード５０Ｂのメモリライブラリ８０２ＢがステップＳ１２，Ｓ１７，Ｓ１９で行う処理の詳細な手順を示すフローチャートである。 同実施の形態にかかるルートノード５０Ａのメモリデーモン８０３ＡがステップＳ１３，Ｓ１６で行う処理の詳細な手順を示すフローチャートである。 同実施の形態にかかるリーフノード５０Ｂのメモリデバイスドライバ８０５ＢがステップＳ１８で行う処理の詳細な手順を示すフローチャートである。 同実施の形態にかかるリーフノード５０Ｃが自身の有するリモートメモリ６０２Ｃにアクセスする場合の処理の手順を示すフローチャートである。 同実施の形態にかかるリーフノード５０Ｃが自身の有するメインメモリ５０１Ｃに割り当てられたリモートメモリ６０２Ｃの利用を終了する処理の手順を示すフローチャートである。 同実施の形態にかかるリーフノード５０Ｂがリモートメモリ６０２Ｃを解放する処理の手順を示すシーケンスチャートである。 同実施の形態にかかるリーフノード５０Ｂのメモリライブラリ８０２ＢがステップＳ２０１，Ｓ２０３で行う処理の詳細な手順を示すフローチャートである。 同実施の形態にかかるリーフノード５０Ｂのメモリデバイスドライバ８０５ＢがステップＳ２０２で行う処理の詳細な手順を示すフローチャートである。 同実施の形態にかかるルートノード５０Ａのメモリデーモン８０３ＡがステップＳ２０５で行う処理の詳細な手順を示すフローチャートである。 同実施の形態にかかるリーフノード５０Ｂのメモリライブラリ８０２ＢがステップＳ２１１で行う処理の詳細な手順を示すフローチャートである。 同実施の形態にかかるリーフノード５０Ｃのメモリデーモン８０３ＣがステップＳ２１２で行う処理の詳細な手順を示すフローチャートである。 同実施の形態にかかるリーフノード５０Ｃのメモリデバイスドライバ８０５ＣがステップＳ２１３で行う処理の詳細な手順を示すフローチャートである。 同実施の形態にかかるプロセッサノード５０ＢのＣＰＵ５００Ｂがプロセッサノード５０Ｃのリモートメモリ６０２Ｃに対して読み出しする処理の手順を簡略的に示すタイミングチャートである。 同実施の形態にかかるプロセッサノード５０ＢのＣＰＵ５００Ｂがプロセッサノード５０Ｃのリモートメモリ６０２Ｃに対して書き込みする処理の手順を簡略的に示すタイミングチャートである。 同実施の形態にかかるリーフノード５０Ｂとリーフノード５０Ｃとで各々動作するプロセス間で双方向に大量のデータをやり取りする場合のデータフローを示す図である。 同実施の形態にかかるリーフノード５０Ｃのメモリデバイスドライバ８０５Ｃがリモートメモリ６０２Ｃのためのメモリ領域を物理アドレスが連続的となるようメモリプールとして確保した状態を例示する図である。 同実施の形態にかかるＯＳ８０４が管理しているメモリ空間６００において空きメモリの物理アドレスが断片化された状態を示す図である。 同実施の形態にかかるメモリウィンドウ６０３をまとめ書き可能領域として設定した場合に、ＣＰＵ５００がメモリウィンドウ６０３に対して連続的に書き込みを行った時のバスサイクルの様子を示す図である。 同実施の形態にかかるメモリウィンドウ６０３をまとめ書き不可領域として設定した場合に、ＣＰＵ５００がメモリウィンドウ６０３に対して連続的に書き込みを行った時のバスサイクルの様子を示す図である。 同実施の形態にかかるライトバッファ５０８をメモリコントローラ５０２´に設けたプロセッサノード５０´の構成を例示する図である。 同実施の形態にかかるライトバッファ５０８をＣＰＵ５００´に設けたプロセッサノード５０"の構成を例示する図である。 同実施の形態にかかるプロセッサノード５０Ｂがキャッシュメモリ９００Ｂを有し、プロセッサノード５０Ｃがキャッシュメモリ９００Ｃを有し、各メモリウィンドウ６０３Ｂ〜６０３Ｃに対してキャッシュメモリ９００Ｂ〜９００Ｃを無効にした場合の動作を概念的に例示した図である。 同実施の形態にかかる各メモリウィンドウ６０３Ｂ〜６０３Ｃに対してキャッシュメモリ９００Ｂ〜９００Ｃを有効にした動作を概念的に例示した図である。
符号の説明
５０ プロセッサノード
５１ 通信回線
５２ 通信回線
５３ メモリマッピングスイッチ
５００ ＣＰＵ
５０１ メインメモリ
５０２ メモリコントローラ
５０３ ホスト−ＰＣＩブリッジ
５０４ Ethernetカード
５０５ メモリマッピングカード
５０６ ＰＣＩデバイス
５０８ ライトバッファ
５１０ ホストバス
６００ メモリ空間
６０１ アドレス空間
６０２ リモートメモリ
６０３ メモリウィンドウ
８０１ ユーザプログラム
８０２ メモリライブラリ
８０３ メモリデーモン
８０５ メモリデバイスドライバ
８０６Ａ メモリマッパ管理デーモン
９００ キャッシュメモリ
ＳＹＭ マルチプロセッサシステム

Claims (11)

  1. 各々独立したメモリ空間が構成されるメモリを各々有する複数のプロセッサノードが複数の通信回線を介して接続され、
    複数の前記プロセッサノードのそれぞれは、
    プログラムの実行により動作するプロセスからの要求に従って、自身の有する前記メモリにおいて構成されるメモリ空間に他のプロセッサノードのメモリの一部又は全部をリモートメモリとしてマッピングするメモリマッピングを行うメモリマッピング手段と、
    第１の通信回線を介して通信する第１通信手段と、
    第２の通信回線を介して通信する第２通信手段とを各々有し、
    複数の前記プロセッサノードのうち１つのプロセッサノードは、
    前記メモリマッピング手段が前記メモリマッピングを行う場合、前記プロセッサノードと前記他のプロセッサノードとの間のマッピングコネクションを作成するメモリマッピング管理手段を更に有し、
    前記メモリマッピング手段は、前記他のプロセッサノードの有する他のメモリマッピング手段に対して前記リモートメモリの割り当てを要求するメモリ割り当て要求を、前記第２通信手段を介して送信し、前記１つのプロセッサノードが有する前記メモリマッピング管理手段に対して前記マッピングコネクションの作成を要求するコネクション作成要求を、前記第２通信手段を介して送信し、
    前記メモリマッピング管理手段は、前記メモリマッピング手段から送信された前記コネクション作成要求に従って、前記プロセッサノードと前記他のプロセッサノードとの間のマッピングコネクションを作成した後、前記メモリマッピング手段に対して前記メモリマッピングの実行を指示するメモリマッピング指示を、前記１つのプロセッサノードが有する第１通信手段を介して送信する
    ことを特徴とするマルチプロセッサシステム。
  2. 前記他のメモリマッピング手段は、前記リモートメモリの割り当てが要求された場合、前記他のプロセッサノードが有する他のメモリの全部又は一部のメモリ領域をリモートメモリとして割り当て、当該メモリ領域のアドレスを含むメモリ割り当て結果を、当該他のプロセッサノードが有する他の第２通信手段を介して前記メモリマッピング手段に送信する
    ことを特徴とする請求項１に記載のマルチプロセッサシステム。
  3. 前記メモリマッピング手段は、前記他のメモリマッピング手段に対して前記メモリ割り当て要求を前記第２通信手段を介して送信した後、前記他のメモリマッピング手段が送信した前記メモリ領域のアドレスを含むメモリ割り当て結果を受信した場合、前記メモリマッピング管理手段に対して、前記メモリ領域のアドレスを含む前記コネクション作成要求を前記第２通信手段を介して送信し、
    前記メモリマッピング管理手段は、前記メモリマッピング手段が送信した前記コネクション作成要求に従って、前記プロセッサノードに対して設定されているメモリウィンドウのアドレスに対して前記メモリ領域のアドレスをマッピングすることによりマッピングコネクションを作成した後、前記メモリマッピング手段に対して前記メモリマッピングの実行を指示するメモリマッピング指示を、前記１つのプロセッサノードが有する第１通信手段を介して送信する
    ことを特徴とする請求項２に記載のマルチプロセッサシステム。
  4. 前記メモリマッピング手段は、前記メモリマッピング管理手段が送信した前記メモリマッピング指示を、前記第１通信手段を介して受信した場合、前記メモリ領域のアドレスについて、自身の有する前記メモリにおいて構成されるメモリ空間であり且つ前記プロセスにより生成される仮想メモリ空間にマッピングすることにより、前記メモリマッピングを行う
    ことを特徴とする請求項３に記載のマルチプロセッサシステム。
  5. 複数の前記プロセッサノードは、記憶手段に記憶されたＯＳ（Operating System）を読み出してこれを実行することにより当該プロセッサノードを制御する制御手段を各々有し、
    前記他のメモリマッピング手段は、前記ＯＳの起動時に、前記メモリにおいてアドレスが連続しているメモリ領域を確保し、前記メモリマッピング手段から前記リモートメモリの割り当てが要求された場合、確保したメモリ領域の一部又は全部をリモートメモリとして割り当て、当該メモリ領域のアドレスを含むメモリ割り当て結果を、前記他の第２通信手段を介して前記メモリマッピング手段に送信する
    ことを特徴とする請求項３又は４に記載のマルチプロセッサシステム。
  6. 前記メモリマッピング手段は、前記他のプロセッサノードの有する他のメモリマッピング手段に対して、前記リモートメモリのメモリサイズを指定して当該リモートメモリの割り当てを要求するメモリ割り当て要求を、前記第２通信手段を介して送信し、
    前記他のメモリマッピング手段は、前記メモリサイズが指定された前記リモートメモリの割り当てが要求されると、前記他のメモリのメモリ領域のうち前記メモリサイズのメモリ領域をリモートメモリとして割り当て、当該メモリ領域のアドレスを含むメモリ割り当て結果を、前記他のプロセッサノードが有する他の第２通信手段を介して前記メモリマッピング手段に送信する
    ことを特徴とする請求項２乃至５のいずれか一項に記載のマルチプロセッサシステム。
  7. 前記メモリマッピング手段は、Ｓｙｓｔｅｍ Ｖ ＩＰＣに含まれる共有メモリ機能が実現される際に用いられるＡＰＩと同等のＡＰＩを提供するメモリライブラリを含む
    ことを特徴とする請求項１乃至６のいずれか一項に記載のマルチプロセッサシステム。
  8. 前記プロセッサノードに対して設定されているメモリウィンドウの一部又は全部は、まとめ書き込み可能なメモリ領域である
    ことを特徴とする請求項３乃至７のいずれか一項に記載のマルチプロセッサシステム。
  9. 複数の前記プロセッサノードは、各々Ｐ２Ｐ（Peer to Peer）の関係で接続され、
    前記１つのプロセッサノードと、当該１つのプロセッサノード以外のプロセッサノードとはサーバとクライアントとの関係で接続される
    ことを特徴とする請求項１乃至８のいずれか一項に記載のマルチプロセッサシステム。
  10. 前記第２の通信回線は、所定の通信規格に従って通信するためのネットワーク通信回線である
    ことを特徴とする請求項１乃至９のいずれか一項に記載のマルチプロセッサシステム。
  11. 前記プロセッサノードは、
    Ｉ／Ｏ(Input/Output)デバイスに対してデータの書き込みを要求する書き込み要求を送るＣＰＵ（Central Processing Unit）と、
    前記ＣＰＵが接続されるホストバスと、
    前記Ｉ／Ｏデバイスが接続される汎用バスと、
    前記ホストバスと前記汎用バスとを接続するホストバスブリッジと、
    前記ＣＰＵと前記ホストバスブリッジとの間に設けられたライトバッファとを有し、
    前記ライトバッファは、前記ＣＰＵから送られる前記書き込み要求をバッファリングして、前記汎用バスに対してバースト転送サイクルを発行する
    ことを特徴とする請求項１に記載のマルチプロセッサシステム。
JP2008234313A 2007-09-14 2008-09-12 マルチプロセッサシステム Expired - Fee Related JP5347396B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008234313A JP5347396B2 (ja) 2007-09-14 2008-09-12 マルチプロセッサシステム

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2007240025 2007-09-14
JP2007240025 2007-09-14
JP2008234313A JP5347396B2 (ja) 2007-09-14 2008-09-12 マルチプロセッサシステム

Publications (2)

Publication Number Publication Date
JP2009087335A JP2009087335A (ja) 2009-04-23
JP5347396B2 true JP5347396B2 (ja) 2013-11-20

Family

ID=40455821

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008234313A Expired - Fee Related JP5347396B2 (ja) 2007-09-14 2008-09-12 マルチプロセッサシステム

Country Status (2)

Country Link
US (1) US7979645B2 (ja)
JP (1) JP5347396B2 (ja)

Families Citing this family (86)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003058879A1 (en) 2002-01-08 2003-07-17 Seven Networks, Inc. Secure transport for mobile communication network
US8468126B2 (en) 2005-08-01 2013-06-18 Seven Networks, Inc. Publishing data in an information community
US7917468B2 (en) 2005-08-01 2011-03-29 Seven Networks, Inc. Linking of personal information management data
US7853563B2 (en) 2005-08-01 2010-12-14 Seven Networks, Inc. Universal data aggregation
US7441271B2 (en) 2004-10-20 2008-10-21 Seven Networks Method and apparatus for intercepting events in a communication system
US7706781B2 (en) 2004-11-22 2010-04-27 Seven Networks International Oy Data security in a mobile e-mail service
FI117152B (fi) 2004-12-03 2006-06-30 Seven Networks Internat Oy Sähköpostiasetusten käyttöönotto matkaviestimelle
US7752633B1 (en) 2005-03-14 2010-07-06 Seven Networks, Inc. Cross-platform event engine
US8438633B1 (en) 2005-04-21 2013-05-07 Seven Networks, Inc. Flexible real-time inbox access
WO2006136660A1 (en) 2005-06-21 2006-12-28 Seven Networks International Oy Maintaining an ip connection in a mobile network
US7769395B2 (en) 2006-06-20 2010-08-03 Seven Networks, Inc. Location-based operations and messaging
US7822802B2 (en) * 2006-09-29 2010-10-26 Fisher-Rosemount Systems, Inc. Apparatus and method for merging wireless data into an established process control system
US8693494B2 (en) 2007-06-01 2014-04-08 Seven Networks, Inc. Polling
US8805425B2 (en) 2007-06-01 2014-08-12 Seven Networks, Inc. Integrated messaging
US8364181B2 (en) 2007-12-10 2013-01-29 Seven Networks, Inc. Electronic-mail filtering for mobile devices
US9002828B2 (en) 2007-12-13 2015-04-07 Seven Networks, Inc. Predictive content delivery
US8107921B2 (en) 2008-01-11 2012-01-31 Seven Networks, Inc. Mobile virtual network operator
US8862657B2 (en) 2008-01-25 2014-10-14 Seven Networks, Inc. Policy based content service
US20090193338A1 (en) 2008-01-28 2009-07-30 Trevor Fiatal Reducing network and battery consumption during content delivery and playback
US8787947B2 (en) 2008-06-18 2014-07-22 Seven Networks, Inc. Application discovery on mobile devices
US8078158B2 (en) 2008-06-26 2011-12-13 Seven Networks, Inc. Provisioning applications for a mobile device
US8909759B2 (en) 2008-10-10 2014-12-09 Seven Networks, Inc. Bandwidth measurement
US8849972B2 (en) 2008-11-25 2014-09-30 Polycom, Inc. Method and system for dispatching received sessions between a plurality of instances of an application using the same IP port
KR101198400B1 (ko) * 2008-12-16 2012-11-07 한국전자통신연구원 메모리 관리 장치 및 방법
CN102110072B (zh) * 2009-12-29 2013-06-05 中兴通讯股份有限公司 一种多处理器完全互访的方法及系统
US9043433B2 (en) 2010-07-26 2015-05-26 Seven Networks, Inc. Mobile network traffic coordination across multiple applications
CA2857458A1 (en) 2010-07-26 2012-02-09 Michael Luna Mobile application traffic optimization
GB2495877B (en) 2010-07-26 2013-10-02 Seven Networks Inc Distributed implementation of dynamic wireless traffic policy
US8838783B2 (en) 2010-07-26 2014-09-16 Seven Networks, Inc. Distributed caching for resource and mobile network traffic management
US9330196B2 (en) 2010-11-01 2016-05-03 Seven Networks, Llc Wireless traffic management system cache optimization using http headers
US8843153B2 (en) 2010-11-01 2014-09-23 Seven Networks, Inc. Mobile traffic categorization and policy for network use optimization while preserving user experience
WO2012060997A2 (en) 2010-11-01 2012-05-10 Michael Luna Application and network-based long poll request detection and cacheability assessment therefor
US8326985B2 (en) 2010-11-01 2012-12-04 Seven Networks, Inc. Distributed management of keep-alive message signaling for mobile network resource conservation and optimization
WO2012060995A2 (en) 2010-11-01 2012-05-10 Michael Luna Distributed caching in a wireless network of content delivered for a mobile application over a long-held request
US8484314B2 (en) 2010-11-01 2013-07-09 Seven Networks, Inc. Distributed caching in a wireless network of content delivered for a mobile application over a long-held request
EP2635973A4 (en) 2010-11-01 2014-01-15 Seven Networks Inc TO THE BEHAVIOR OF A MOBILE APPLICATION AND INTERMEDIATE STORAGE TAILORED TO NETWORK CONDITIONS
US9060032B2 (en) 2010-11-01 2015-06-16 Seven Networks, Inc. Selective data compression by a distributed traffic management system to reduce mobile data traffic and signaling traffic
CN103404193B (zh) 2010-11-22 2018-06-05 七网络有限责任公司 调校数据传输以优化为通过无线网络的传输建立的连接
EP2636268B1 (en) 2010-11-22 2019-02-27 Seven Networks, LLC Optimization of resource polling intervals to satisfy mobile device requests
US9325662B2 (en) 2011-01-07 2016-04-26 Seven Networks, Llc System and method for reduction of mobile network traffic used for domain name system (DNS) queries
JP5627506B2 (ja) * 2011-02-24 2014-11-19 三菱電機株式会社 データ処理装置
JP2012205088A (ja) * 2011-03-25 2012-10-22 Toshiba Corp ノード及びグループ鍵更新方法
EP2700020A4 (en) 2011-04-19 2015-01-07 Seven Networks Inc SHARING DEVICE RESOURCES FOR NETWORK RESOURCE CONSERVATION
US8621075B2 (en) 2011-04-27 2013-12-31 Seven Metworks, Inc. Detecting and preserving state for satisfying application requests in a distributed proxy and cache system
GB2504037B (en) 2011-04-27 2014-12-24 Seven Networks Inc Mobile device which offloads requests made by a mobile application to a remote entity for conservation of mobile device and network resources
EP2737742A4 (en) 2011-07-27 2015-01-28 Seven Networks Inc AUTOMATIC PRODUCTION AND DISTRIBUTION OF GUIDELINES INFORMATION ON MOBILE MOBILE TRANSPORT IN A WIRELESS NETWORK
US8918503B2 (en) 2011-12-06 2014-12-23 Seven Networks, Inc. Optimization of mobile traffic directed to private networks and operator configurability thereof
WO2013086214A1 (en) 2011-12-06 2013-06-13 Seven Networks, Inc. A system of redundantly clustered machines to provide failover mechanisms for mobile traffic management and network resource conservation
US9277443B2 (en) 2011-12-07 2016-03-01 Seven Networks, Llc Radio-awareness of mobile device for sending server-side control signals using a wireless network optimized transport protocol
GB2498064A (en) 2011-12-07 2013-07-03 Seven Networks Inc Distributed content caching mechanism using a network operator proxy
US8861354B2 (en) 2011-12-14 2014-10-14 Seven Networks, Inc. Hierarchies and categories for management and deployment of policies for distributed wireless traffic optimization
US9832095B2 (en) 2011-12-14 2017-11-28 Seven Networks, Llc Operation modes for mobile traffic optimization and concurrent management of optimized and non-optimized traffic
EP2792188B1 (en) 2011-12-14 2019-03-20 Seven Networks, LLC Mobile network reporting and usage analytics system and method using aggregation of data in a distributed traffic optimization system
EP2801236A4 (en) 2012-01-05 2015-10-21 Seven Networks Inc DETECTION AND MANAGEMENT OF USER INTERACTIONS WITH FRONT PANEL APPLICATIONS ON A MOBILE DEVICE IN DISTRIBUTED CACHE STORES
US9203864B2 (en) 2012-02-02 2015-12-01 Seven Networks, Llc Dynamic categorization of applications for network access in a mobile network
US9326189B2 (en) 2012-02-03 2016-04-26 Seven Networks, Llc User as an end point for profiling and optimizing the delivery of content and data in a wireless network
US8812695B2 (en) 2012-04-09 2014-08-19 Seven Networks, Inc. Method and system for management of a virtual network connection without heartbeat messages
US20130268656A1 (en) 2012-04-10 2013-10-10 Seven Networks, Inc. Intelligent customer service/call center services enhanced using real-time and historical mobile application and traffic-related statistics collected by a distributed caching system in a mobile network
US9104560B2 (en) 2012-06-13 2015-08-11 Caringo, Inc. Two level addressing in storage clusters
US8762353B2 (en) 2012-06-13 2014-06-24 Caringo, Inc. Elimination of duplicate objects in storage clusters
US8799746B2 (en) 2012-06-13 2014-08-05 Caringo, Inc. Erasure coding and replication in storage clusters
WO2014011216A1 (en) 2012-07-13 2014-01-16 Seven Networks, Inc. Dynamic bandwidth adjustment for browsing or streaming activity in a wireless network based on prediction of user behavior when interacting with mobile applications
US9161258B2 (en) 2012-10-24 2015-10-13 Seven Networks, Llc Optimized and selective management of policy deployment to mobile clients in a congested network to prevent further aggravation of network congestion
US20140177497A1 (en) 2012-12-20 2014-06-26 Seven Networks, Inc. Management of mobile device radio state promotion and demotion
US9271238B2 (en) 2013-01-23 2016-02-23 Seven Networks, Llc Application or context aware fast dormancy
US8874761B2 (en) 2013-01-25 2014-10-28 Seven Networks, Inc. Signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols
CN103136110B (zh) 2013-02-18 2016-03-30 华为技术有限公司 内存管理方法、内存管理装置及numa系统
US8750123B1 (en) 2013-03-11 2014-06-10 Seven Networks, Inc. Mobile device equipped with mobile network congestion recognition to make intelligent decisions regarding connecting to an operator network
CN108845877B (zh) * 2013-05-17 2021-09-17 华为技术有限公司 管理内存的方法、装置和系统
US9338918B2 (en) 2013-07-10 2016-05-10 Samsung Electronics Co., Ltd. Socket interposer and computer system using the socket interposer
US9065765B2 (en) 2013-07-22 2015-06-23 Seven Networks, Inc. Proxy server associated with a mobile carrier for enhancing mobile traffic management in a mobile network
TWI514142B (zh) * 2013-11-26 2015-12-21 Synology Inc 儲存系統及其控制方法
US9529616B2 (en) 2013-12-10 2016-12-27 International Business Machines Corporation Migrating processes between source host and destination host using a shared virtual file system
US9411644B2 (en) 2014-03-07 2016-08-09 Cavium, Inc. Method and system for work scheduling in a multi-chip system
US9529532B2 (en) * 2014-03-07 2016-12-27 Cavium, Inc. Method and apparatus for memory allocation in a multi-node system
US10592459B2 (en) 2014-03-07 2020-03-17 Cavium, Llc Method and system for ordering I/O access in a multi-node environment
US9372800B2 (en) 2014-03-07 2016-06-21 Cavium, Inc. Inter-chip interconnect protocol for a multi-chip system
US9632973B2 (en) 2014-09-02 2017-04-25 Intel Corporation Supporting RMA API over active message
TWI588742B (zh) * 2015-07-27 2017-06-21 晨星半導體股份有限公司 應用程式的程式碼載入方法及應用其方法的電腦系統
CN106484446A (zh) * 2015-08-28 2017-03-08 晨星半导体股份有限公司 应用程序的程序代码载入方法及应用其方法的电脑系统
US10078615B1 (en) * 2015-09-18 2018-09-18 Aquantia Corp. Ethernet controller with integrated multi-media payload de-framer and mapper
CN105224246B (zh) * 2015-09-25 2018-11-09 联想(北京)有限公司 一种信息以及内存配置方法和装置
US10067879B2 (en) * 2015-12-16 2018-09-04 Intel Corporation Apparatus and method to support a storage mode over a cache-line memory interface to a non-volatile memory dual in line memory module
US10380012B2 (en) * 2016-04-22 2019-08-13 Samsung Electronics Co., Ltd. Buffer mapping scheme involving pre-allocation of memory
US10700711B1 (en) 2017-11-03 2020-06-30 Caringo Inc. Multi-part upload and editing of erasure-coded objects
CN110928682B (zh) * 2019-11-13 2023-06-09 深圳国微芯科技有限公司 外部设备访问计算机内存的方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0619785A (ja) * 1992-03-27 1994-01-28 Matsushita Electric Ind Co Ltd 分散共有仮想メモリーとその構成方法
JP3544390B2 (ja) * 1994-06-29 2004-07-21 富士通株式会社 並列計算機で用いられるメッセージ通信方法
US5961606A (en) * 1997-06-30 1999-10-05 Sun Microsystems, Inc. System and method for remote buffer allocation in exported memory segments and message passing between network nodes
JP2001331457A (ja) 2000-05-19 2001-11-30 Ricoh Co Ltd 分散共有メモリ方式
JP2003330905A (ja) * 2002-05-14 2003-11-21 Nec Corp コンピュータシステム
US7219343B2 (en) * 2003-04-10 2007-05-15 International Business Machines Corporation Firmware update mechanism in a multi-node data processing system
US7222262B2 (en) * 2003-08-05 2007-05-22 Newisys, Inc. Methods and devices for injecting commands in systems having multiple multi-processor clusters
US7702742B2 (en) * 2005-01-18 2010-04-20 Fortinet, Inc. Mechanism for enabling memory transactions to be conducted across a lossy network

Also Published As

Publication number Publication date
US7979645B2 (en) 2011-07-12
JP2009087335A (ja) 2009-04-23
US20090077326A1 (en) 2009-03-19

Similar Documents

Publication Publication Date Title
JP5347396B2 (ja) マルチプロセッサシステム
US10877695B2 (en) Memcached server functionality in a cluster of data processing nodes
US10140245B2 (en) Memcached server functionality in a cluster of data processing nodes
US10031857B2 (en) Address translation services for direct accessing of local memory over a network fabric
US10135731B2 (en) Remote memory access functionality in a cluster of data processing nodes
CN107690622B (zh) 实现硬件加速处理的方法、设备和系统
US9648102B1 (en) Memcached server functionality in a cluster of data processing nodes
US8250254B2 (en) Offloading input/output (I/O) virtualization operations to a processor
KR101684490B1 (ko) 클러스터 레벨에서의 데이터 일관성 모델 및 프로토콜
JP2021190125A (ja) メモリリソースを管理するためのシステム及び方法
US9529532B2 (en) Method and apparatus for memory allocation in a multi-node system
US11693804B2 (en) Cross bus memory mapping
JPH1185710A (ja) サーバ装置およびファイル管理方法
US20150370721A1 (en) Mapping mechanism for large shared address spaces
US20240012581A1 (en) Memcached Server Functionality in a Cluster of Data Processing Nodes
CN112540941A (zh) 一种数据转发芯片及服务器
JP2023524665A (ja) ネットワーク・スタック・フレームワークにおいてコヒーレントにアタッチされたインターフェースを利用すること
JP2008021252A (ja) 計算機システム及びアドレス割当方法
KR101565172B1 (ko) 대규모 병렬 프로세서 어레이 시스템의 데이터 처리 장치 및 방법
US20090304011A1 (en) Network Interface and Router with a Mass Storage Interface Device Emulating a Hard Disk Controller
US20230393970A1 (en) Global virtual address space across operating system domains
US20050071545A1 (en) Method for embedding a server into a storage subsystem
WO2005015349A2 (en) Method for embedding a server into a storage subsystem

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110805

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130426

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130521

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130705

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130723

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130805

LAPS Cancellation because of no payment of annual fees