JP6369286B2 - プロセス間通信プログラム、解放要求方法、および並列演算装置 - Google Patents

Description

本発明は、プロセス間通信プログラム、解放要求方法、および並列演算装置に関する。

ＨＰＣ（High Performance Computing）などにおける並列プログラムでは、プロセス間でデータの送受信が頻繁に行われる。プロセス間でデータを送受信するには、ユーザによる送受信用のデータ領域が確保される。更にＭＰＩ（Message Passing Interface）などの通信ライブラリが内部で使用するためのバッファ領域が確保される。プロセス間通信では、確保した領域の先頭アドレスと先頭アドレスからのオフセットを指定して、データの送受信が行われる。

プロセス間通信のためにユーザ空間に確保されたメモリ領域（送受信領域）は、ＯＳ（Operating System）で管理される。ＯＳは、プロセス間通信のための送受信用のバッファの管理のため、例えばその確保されたメモリ領域と一対一に対応するステアリングと呼ばれる管理表を用いる。ＯＳのネットワークインターフェース（ＮＩ）ドライバは、ステアリングとそれにつけられたステアリングのタグ（ＳＴａｇ）によってユーザの使用する送受信領域を特定する。

ステアリングおよびＳＴａｇはユーザ空間で送受信用のバッファの獲得を行った際に、ＯＳが管理するカーネル空間内のメモリ領域に格納される。そしてＯＳは、バッファを解放した場合、ステアリングおよびＳＴａｇの登録を解除し、ステアリングおよびＳＴａｇが格納されていた記憶領域を再利用できるようする。

なおホストメモリ間通信に関して、通信の効率化に関するいくつかの技術が考えられている。例えば、通信回線への無駄なトラヒックの流入の抑制と、データ受信側コンピュータ装置のマイクロプロセッサの負荷抑制を行う技術がある。また、ＲＮＩＣ（Remote direct memory access enabled Network Interface Controller）による効率的ｉＳＣＳＩ（Internet Small Computer System Interface）オフロード・インプリメンテーションに関する技術もある。

特開２００７−３０４７８６号公報 特表２００８−５２９１０９号公報

従来、プロセス間通信の送受信用のバッファが解放されると、１つずつ、ステアリングおよびＳＴａｇの登録解除が行われる。しかし、バッファの解放のたびにＳＴａｇの登録解除処理が発生することによってオーバーヘッドが増えてしまうという問題がある。しかも、使用頻度の高いステアリングおよびＳＴａｇを再利用しようとする場合は、再登録のオーバーヘッドも加算されてしまう。例えば、ＳＴａｇの登録解除を行う場合、システムコールとハードアクセスで一回あたり４〜５μ秒のオーバーヘッドがかかる。それに対し、簡単なプロセス間通信であれば、一対一通信が実行される時間は１μ秒程度である。そうするとプロセス間通信を行うために実行されるＳＴａｇの登録解除のコストが、プロセス間通信のコストに比べ約４〜５倍もかかってしまう。その結果、プロセス間通信を伴う処理全体の効率が低下する。

１つの側面では、本発明は、プロセス間通信を伴う処理の効率化を図ることを目的とする。

１つの案では、コンピュータに、以下の処理を実行させるプロセス間通信プログラムが提供される。プロセス間通信プログラムに基づいて、コンピュータは、プロセス間通信対象のデータを格納するバッファの管理情報を記憶する記憶領域の解放を要求する第１解放要求が出力されるごとに、第１解放要求を蓄積する。次にコンピュータは、蓄積された第１解放要求の数が閾値に達すると、蓄積された第１解放要求のうちの少なくとも一部を、実行対象の第１解放要求として選択する。そしてコンピュータは、実行対象の第１解放要求に示されている管理情報の記憶領域の解放をまとめて要求する第２解放要求を出力する。

１態様によれば、プロセス間通信を伴う処理の効率化を図ることができる。

第１の実施の形態に係る並列演算装置の例を示す図である。 第２の実施の形態のシステム構成例を示す図である。 第２の実施の形態に用いるノードのハードウェアの一構成例を示す図である。 プロセス間通信のための通信機能を示す図である。 プロセス間通信の様子を示す図である。 ステアリングとＳＴａｇの例を示す図である。 ＳＴａｇを用いたプロセス間通信の例を示す図である。 ＳＴａｇの一斉解放の管理を行うために通信管理部が保持する情報を示す図である。 ＳＴａｇ問い合わせ処理の手順の一例を示すフローチャートである。 ＳＴａｇの登録解除処理手順の第１の例を示すフローチャートである。 ＳＴａｇの登録解除処理手順の第２の例を示すフローチャートである。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
第１の実施の形態は、並列演算装置において、プロセス間通信のために確保されたバッファの管理情報のメモリ領域からの解放要求を効率的に行うものである。

図１は、第１の実施の形態に係る並列演算装置の例を示す図である。並列演算装置１０は、記憶部１１と演算部１２とを有する。記憶部１１は、例えばメモリである。演算部１２は、例えば１または複数のプロセッサである。演算部１２は、複数のプロセス１３ａ，１３ｂ，１３ｃ，・・・、プロセス間通信管理部１６、およびＯＳ１７を含む。複数のプロセス１３ａ，１３ｂ，１３ｃ，・・・、プロセス間通信管理部１６、およびＯＳ１７は、例えばプログラムモジュールを演算部１２で実行することにより実現される。

並列演算装置１０は、複数のプロセス１３ａ，１３ｂ，１３ｃ，・・・により、並列演算を行う。複数のプロセス１３ａ，１３ｂ，１３ｃ，・・・は、プロセス間通信管理部１６を介して、互いに通信することができる。プロセス間通信管理部１６は、プロセス間通信に関するＯＳ１７への処理要求を管理する。プロセス間通信は、他の装置内のプロセスとの間でも行うことができる。

プロセス間通信を行う場合、複数のプロセス１３ａ，１３ｂ，１３ｃ，・・・それぞれについて、通信用のバッファ１４ａ，１４ｂ，１４ｃ，・・・が記憶部１１のユーザ空間内に確保される。通信用のバッファ１４ａ，１４ｂ，１４ｃ，・・・は、通信相手ごとに確保される。また通信用のバッファ１４ａ，１４ｂ，１４ｃ，・・・は、送信用のバッファと受信用のバッファとが別に確保される。

バッファ１４ａ，１４ｂ，１４ｃ，・・・それぞれに対応付けて、記憶部１１のカーネル空間内に設けられた管理情報記憶領域１８に、管理情報１８ａ，１８ｂ，１８ｃ，・・・が格納される。管理情報１８ａ，１８ｂ，１８ｃ，・・・には、対応するバッファが格納された記憶領域のアドレスなどの情報が設定されている。カーネル空間で動作するＯＳ１７は、管理情報１８ａ，１８ｂ，１８ｃ，・・・により、プロセス間通信の際の送信元のデータの格納場所や、送信先のデータの格納場所を認識する。また、管理情報１８ａ，１８ｂ，１８ｃ，・・・には、識別子１９ａ，１９ｂ，１９ｃ，・・・が付与されている。

例えばプロセス１３ａがプロセス間通信を行う際には、通信相手に対応して確保した送信用のバッファにデータを格納する。そしてプロセス１３ａは、データの送信をＯＳ１７に依頼する。その際、管理情報の識別子を指定することで、送信元のデータを格納したバッファや、データの送信先となるバッファが指定される。ＯＳ１７は、例えばＲＤＭＡ（Remote Direct Memory Access）により、送信先のプロセスが確保した受信用のバッファ内に、データを格納する。プロセス間通信が終了すると、プロセス１３ａは、使用したバッファの管理情報の解放を要求する第１解放要求１を出力する。第１解放要求１には、例えば管理情報の識別子が１つだけ含まれる。

ここで、複数のプロセス１３ａ，１３ｂ，１３ｃ，・・・それぞれが第１解放要求１を出力するごとに、その第１解放要求１をＯＳ１７に送信してしまうと、ＯＳ１７への解放要求の頻度が高くなる。その結果、プロセス間通信を伴う処理全体の処理効率が低下する。

そこで第１の実施の形態では、プロセス間通信管理部１６が、第１解放要求１が出力されるごとに、第１解放要求１を、記憶部１１のユーザ空間内に設けられた解放候補リスト１５に蓄積する。解放候補リスト１５には、例えば、出力された時期が古い方から順に、第１解放要求１が並べて格納される。なお同一の管理情報に関する第１解放要求が複数出力された場合、最後に出力された第１解放要求のみを蓄積する。プロセス間通信管理部１６は、蓄積された第１解放要求の数が閾値ｎ（ｎは１以上の整数）に達すると、蓄積された第１解放要求のうちの少なくとも一部を、実行対象の第１解放要求として選択する。例えばプロセス間通信管理部１６は、出力時期が古い方から所定数ｋ（ｋは１以上、ｎ以下の整数）の第１解放要求の中から、実行対象の第１解放要求を選択する。なおプロセス間通信管理部１６は、管理情報を再利用しているか否かを管理することもできる。管理情報の再利用の有無を管理している場合、プロセス間通信管理部１６は、現在再利用されていない管理情報の記憶領域の解放を要求する第１解放要求を、実行対象の第１解放要求として選択することができる。

またプロセス間通信管理部１６は、管理情報記憶領域１８内の空き領域が枯渇しそうなことを検知した場合にも、実行対象の第１解放要求を選択し、第２解放要求２を出力してもよい。管理情報記憶領域１８内の空き領域が枯渇しそうな場合とは、例えば管理情報記憶領域１８内の空き領域が所定値以下になった場合である。

実行対象の第１解放要求を選択すると、プロセス間通信管理部１６は、実行対象の第１解放要求に示されている管理情報の記憶領域の解放をまとめて要求する第２解放要求２を、ＯＳ１７に対して出力する。第２解放要求２には、例えば管理情報の識別子が複数含まれる。

ＯＳ１７は、第２解放要求２に基づいて、管理情報が記憶された記憶領域を解放する。例えばＯＳ１７が管理情報に対する識別子の登録を解除すると、管理情報が記憶された記憶領域が解放される。

なお、上記の閾値ｎは、解放処理にかかる時間の影響が少なくなるように最適に調整されているものとする。閾値ｎが小さすぎると、第２解放要求の出力頻度が高くなり、解放処理の効率化の効果が薄れてしまう。また閾値ｎが大きすぎると、解放候補リスト１５に登録される解放候補が多くなり、解放候補リスト１５内の解放候補の管理のための負荷が大きくなる。例えば、管理情報の再利用の有無の管理負荷や、同じ管理情報に関する解放要求が既に登録されているかどうかの判断処理の負荷が大きくなる。そこで解放候補の管理負荷が過大とならない範囲のできるだけ大きな値が、閾値ｎに設定される。

このように第１の実施の形態では、プロセス１３ａ，１３ｂ，１３ｃから第１解放要求１が出力された場合、その第１解放要求１が順番に解放候補リスト１５に、解放候補として登録される。そして、解放候補である第１解放要求は、解放処理にかかる時間の影響が少なくなるように最適に調整された個数（閾値ｎ）になるまで保持される。解放候補の第１解放要求の数が閾値ｎに達すると、古い方から一定の範囲内の、再利用されていない管理情報の第１解放要求が実行対象として選択される。そして選択された第１解放要求に示されるすべての管理情報の解放をまとめて要求する第２解放要求２がＯＳ１７に対して出力される。するとＯＳ１７により、第２解放要求２に示された管理情報の記憶領域が解放される。解放された記憶領域は、空き領域となる。なお、管理情報記憶領域１８内の空き領域の枯渇が発生しそうな場合は、解放候補として蓄積された第１解放要求１の数が閾値ｎに達していなくても、第２解放要求２による解放処理が行われる。

これにより、ＯＳ１７に対して管理情報の解放を要求する頻度が低くなり、プロセス間通信に伴って発生するオーバーヘッドが抑制される。しかも、再利用されている管理情報に対する第１解放要求１は、実行対象から除外されるため、再利用されている管理情報が、利用中に解放されてしまうことを回避できる。また、出力時期が古い方から所定数の範囲内の第１解放要求を実行対象とすることで、出力時期が新しい第１解放要求は、実行対象から除外される。その結果、短時間で繰り返し使用されるような使用頻度の高い管理情報については解放せずにすみ、使用頻度の高い管理情報について、再利用のたびに新たに管理情報を再設定するような事態の発生を抑止できる。

なお、図１に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
〔第２の実施の形態〕
次に、第２の実施の形態について説明する。第２の実施の形態は、ＯＳによる送受信領域の管理情報としてステアリングを用い、複数のノード間の集団通信を行う例である。

図２は、第２の実施の形態のシステム構成例を示す図である。図２に示すように、複数のノード１００，２００，３００，４００がＮＳ（ネットワークスイッチ）２０を介して接続されている。また複数のノード１００，２００，３００，４００は、バリア同期用ネットワーク２１でも接続されている。バリア同期用ネットワーク２１は、プロセス間のバリア同期用の通信の送受信に用いられる。バリア同期とは、並列で処理を実行するプロセスについて、処理がある箇所まで来ると、他のプロセスが所定の箇所（バリア）に到達するまで、処理を止めておく同期処理である。

図３は、第２の実施の形態に用いるノードのハードウェアの一構成例を示す図である。ノード１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、ノード１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ＨＤＤ（Hard Disk Drive）１０３、ＢＩ（バリアインタフェース）１０４、光学ドライブ装置１０６、機器接続インタフェース１０７およびＮＩ（ネットワークインターフェース）１０８がある。

ＨＤＤ１０３は、内蔵したディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、ノード１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、フラッシュメモリなどの不揮発性の半導体記憶装置を使用することもできる。

ＢＩ（バリアインタフェース）１０４は、バリア同期用ネットワーク２１を介して、他のノード２００，３００，４００との間でバリア同期用の通信を行う。
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、ノード１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ＮＩ１０８は、ＮＳ２０に接続されている。ＮＩ１０８は、ＮＳ２０を介して、他のノード２００，３００，４００との間でデータの送受信を行う。
以上のようなハードウェア構成によって、第２の実施の形態のノード１００の処理機能を実現することができる。他のノード２００，３００，４００も、図３に示したノード１００と同様のハードウェアにより実現することができる。また、第１の実施の形態に示した並列演算装置１０も、図３に示したノード１００と同様のハードウェアにより実現することができる。

ノード１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。ノード１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、ノード１００に実行させるプログラムをＨＤＤ１０３に格納しておくことができる。プロセッサ１０１は、ＨＤＤ１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またノード１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ＨＤＤ１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

以上のようなシステムにより、複数のノード１００，２００，３００，４００を用いた並列処理が実行される。並列処理では、各ノードのプロセス間での通信が発生する。
図４は、プロセス間通信のための通信機能を示す図である。ノード１００は、ＭＰＩ１１０、通信管理部１２０、ＮＩドライバ１３０、およびＮＩ１０８を用いて、プロセス間通信を実現する。ＭＰＩ１１０、通信管理部１２０、ＮＩドライバ１３０、およびＮＩ１０８は階層構造となっており、要求や情報のやり取りは隣接する階層間で行われる。

ＭＰＩ１１０は、並列処理における高度なプロセス間通信環境を提供する通信インタフェースである。ＭＰＩ１１０は、通信管理部１２０とＮＩドライバ１３０とを介してＮＩ１０８を使用する。ＭＰＩ１１０は、例えばＭＰＩライブラリを、ユーザのアプリケーションを実行するプロセスが呼び出すことで使用できる。例えばジョブが実行されると各ノードでＭＰＩ１１０を利用したプロセスが立ち上がり、各プロセスはプロセス間通信を行うため、メモリ領域に通信用のバッファを獲得する。

通信管理部１２０は、ＭＰＩ１１０を用いた通信要求の受け渡しを、ＯＳ内のＮＩドライバ１３０との間で行う。通信管理部１２０は、例えば低レベル通信ライブラリを呼び出すことで利用できる。ＭＰＩ１１０と通信管理部１２０とは、ユーザ空間で動作する。ユーザ空間は、アプリケーションなどが動作するメモリ空間である。なお通信管理部１２０は、図１に示した第１の実施の形態におけるプロセス間通信管理部１６の一例である。

ＮＩドライバ１３０は、ＮＩ１０８を制御する。ＮＩ１０８は、ＮＩドライバ１３０からの指示に応じて、他のノードとの間のデータ通信を行う。ＮＩドライバ１３０は、カーネル空間で動作する。カーネル空間は、ＯＳが使用するメモリ空間である。例えばＮＩドライバ１３０は、ＭＰＩ１１０を利用したプロセスが通信用のバッファが獲得したとき、そのバッファに一意に対応するステアリングをカーネル空間内に用意する。

図４には、ノード１００の通信機能を示しているが、他のノード２００，３００，４００もノード１００と同様の通信機能を備えている。
次に、プロセス間通信について具体的に説明する。並列ジョブのプロセス間通信はノード間の１対１データ通信が元になっている。集団通信は、１対１データ通信の組み合わせとなる。ノード間の１対１データ通信では、送信元のノードのメモリ領域にある送信バッファに書かれたデータが、ＮＩ１０８とＮＳ２０を介して受信ノードのメモリ領域にある受信バッファに書き込まれる。

図５は、プロセス間通信の様子を示す図である。送信プロセス４０は、ユーザ空間内に送信バッファ４１として使用するメモリ領域を確保する。受信プロセス５０は、ユーザ空間内に受信バッファ５１として使用するメモリ領域を確保する。メモリ領域の確保は、例えばＣ言語用に用意された関数のmallocによって行うことができる。

送信プロセス４０は、受信プロセス５０に送信する送信データ４２を、送信バッファ４１内に格納する。そして、送信プロセス４０は、送信データ４２を受信バッファ５１内に送信する。データ転送時には、送信プロセス４０は、送信バッファ４１の先頭のアドレスと、送信データ４２までのオフセットにより、送信データ４２を指定する。また送信プロセス４０は、受信バッファ５１の先頭のアドレスと、データ格納領域までのオフセットにより、データの格納領域を指定する。なお送信プロセスが指定するアドレスは、プロセスごとに設けられた仮想メモリ空間でのアドレスである。

送信されたデータは、受信バッファ５１内に受信データ５２として格納される。そして受信プロセス５０は、受信バッファ５１から受信データ５２を読み出し、受信データ５２を用いた処理を行う。

各プロセスにおけるバッファの確保は、通信相手ごとに行われる。例えばノード１００内のプロセスが、他の３つのノード２００，３００，４００それぞれのプロセスにデータを送信する場合、送信元のプロセスは、送信バッファを３カ所に確保することとなる。

なお、図５では省略しているが、送信プロセス４０から受信プロセス５０へのデータの送信は、ＮＩドライバ１３０とＮＩ１０８とを介して行われる。
次に、ＯＳ内のＮＩドライバ１３０で管理されるステアリングとＳＴａｇについて説明する。

図６は、ステアリングとＳＴａｇの例を示す図である。ＯＳは、カーネル空間のメモリ領域をステアリング記憶部６０とし、ステアリング記憶部６０にステアリング６１，６２，６３，・・・を格納する。ステアリング６１，６２，６３，・・・は、ユーザ空間に確保されたバッファと１対１で対応する。

ステアリング６１，６２，６３，・・・には、プロセスＩＤ、メモリブロック番号、メモリブロック仮想アドレス、サイズなどの情報が含まれる。プロセスＩＤは、ステアリングに対応するバッファ領域を確保したプロセスの識別子である。メモリブロック番号は、プロセスが確保したバッファ領域に対応する実メモリ上でのブロック番号である。メモリブロック仮想アドレスは、プロセスが確保したバッファ領域の仮想アドレスである。サイズは、プロセスが確保したバッファ領域のサイズである。

各ステアリング６１，６２，６３，・・・にはＳＴａｇ７１，７２，７３，・・・が付与されている。ＳＴａｇ７１，７２，７３，・・・は、ステアリングの識別子である。データを送信するプロセスは、ＳＴａｇ７１，７２，７３，・・・を用いて、送信バッファの管理情報であるステアリングを特定できる。ステアリングが特定されれば、そのステアリングに対応する送信バッファの記憶領域も特定される。

図７は、ＳＴａｇを用いたプロセス間通信の例を示す図である。図７の例では、ノード１００内のプロセスがノード２００内のプロセスにデータを送信する場合を想定している。

ノード１００内のユーザ空間には、送信元のプロセス１４０によって送信バッファ１４１が確保されている。送信バッファ１４１には、送信データが格納されている。
そしてノード１００内のプロセス１４０がデータを送信するとき、そのプロセス１４０は、通信管理部１２０を介して、ＮＩドライバ１３０にＳＴａｇの取得を要求する。するとＮＩドライバ１３０が、ステアリング記憶部６０内にステアリングを設け、そのステアリングのＳＴａｇを通信管理部１２０に送信する。これにより、ユーザ空間内の送信バッファ１４１と、送信バッファ１４１の管理用のステアリングとが１対１で対応付けられ、ステアリングがＳＴａｇによって一意に特定される。

同様に受信側のノード２００においても、データの受信側のプロセス２４０が、受信バッファ２４１を確保する。そしてプロセス２４０は、受信バッファ２４１を管理するためのステアリングのＳＴａｇの取得要求を送信する。するとＮＩドライバ２３０が、ステアリング記憶部６０内にステアリングを設け、そのステアリングのＳＴａｇをプロセス２４０に送信する。これにより、ユーザ空間内の受信バッファ２４１と、受信バッファ２４１の管理用のステアリングとが１対１で対応付けられ、ステアリングがＳＴａｇによって一意に特定される。

このとき取得されたノード２００側のＳＴａｇは、所定の取り決めに従って、送信側のプロセス１４０に通知される。例えば、ノード１００，２００間で事前に決めておいたＳＴａｇが示すバッファに、プロセス２４０が取得したＳＴａｇを書き込み、書き込まれたＳＴａｇをプロセス１４０が読み取る（get通信する）。これにより、プロセス１４０は、送付先の受信バッファ２４１を特定するＳＴａｇを取得できる。また、プロセス１４０，２４０間で、使用するＳＴａｇを事前に取り決めておくこともできる。

そして、各ノード１００，２００のＮＩドライバ１３０，２３０を介して、送信データ１４１ａがノード１００からノード２００に送信される。例えばプロセス１４０は、ＳＴａｇにより送信バッファ１４１と受信バッファ２４１とを指定したデータ送信要求を出力する。このデータ送信要求では、例えば送信バッファ１４１内のオフセットで送信データ１４１ａの位置が特定され、受信バッファ２４１内のオフセットで、送信したデータの格納場所が特定される。ＮＩドライバ１３０は、指定されたＳＴａｇに対応するメモリ領域から送信データ１４１ａを取得して、ノード２００に送信する。ノード２００では、ＮＩドライバ２３０がデータを受信し、ＳＴａｇで指定されたステアリングに対応する受信バッファ２４１に、受信データ２４１ａを格納する。

このように、プロセス間通信では、プロセスが用意した送受信用のバッファを管理するため、バッファに一意に対応するステアリングがカーネル空間内に用意される。このステアリングは、ＯＳ内のＮＩドライバ１３０，２３０で管理される。図６に示したように、ステアリングには識別用のＳＴａｇが付与されている。ここで、通信する相手プロセス数が増加した場合、通信相手となるすべてのプロセス分のバッファが確保される。そのため、並列計算における並列の度合いが高くなると、通信相手のプロセスが増え、獲得するバッファ数が増加し、それに伴って、ステアリングおよびＳＴａｇの登録数も増加する。

なおＮＩドライバ１３０，２３０で管理するステアリング数が膨大になると、カーネル空間で使用するメモリ容量が過大となり、システムの処理効率低下の要因となる。そこで、使用していないステアリングの記憶領域は、適宜解放される。ステアリングの記憶領域は、対応するＳＴａｇの登録解除に伴って実施される。すなわち、ＳＴａｇの登録を解除すると、ＳＴａｇに対応するステアリングの登録も解除され、その結果、ステアリングが格納されていた記憶領域が解放される。

ここで、プロセス間通信用に確保したバッファ領域を使用しなくなって解放するごとに、一つ一つＳＴａｇの登録解除をし、ステアリングの記憶領域を解放していたのでは、解放処理が毎回入ることによるオーバーヘッドが増えてしまう。しかも、使用頻度の高いステアリングを再利用しようとする場合、再登録のオーバーヘッドも加算されてしまう。

そこで、例えば、ステアリングおよびＳＴａｇは使われなくなっても保持されたままにして、ＳＴａｇの登録解除およびステアリングの記憶領域の解放は、プロセスが終了した時に一斉に行うことも考えられる。しかし、この場合、プロセス数が非常に多い並列プログラムを実行しようとした場合、ステアリング数が、ステアリング記憶部６０に格納できる上限に達してしまい、ステアリングを登録する記憶領域が枯渇してしまうという問題が発生する。ステアリングを登録する記憶領域の枯渇が発生すると、内部処理の不具合として、通信を行おうとしているプロセスは強制終了されてしまう。プロセスが強制終了すると、そのプロセスで実行しているプログラムの追行が不可能となってしまう。

また、ＭＰＩの集団通信では１対１のデータ通信が複雑に絡み合っており、毎回異なるメモリ領域を使う通信（毎回異なるＳＴａｇを用いる通信）と毎回同じメモリ領域を使う通信（毎回同じＳＴａｇを用いる通信）が混在している。毎回異なるメモリ領域を使う通信ではＳＴａｇの登録解除を毎回行ってもよいが、毎回同じメモリ領域を使う通信の場合、ＳＴａｇの登録解除をデータ通信が終了するごとに行っていたのでは非効率である。

そこで第２の実施の形態では、通信管理部１２０が、使用しなくなったバッファに対応するＳＴａｇを解放候補として登録する。この時点ではＳＴａｇの登録解除は行わない。通信管理部１２０は、解放候補が一定数に達したところでＳＴａｇが再利用されていないか確認をし、使用されていないステアリングのＳＴａｇを一まとめにした解放要求を、ＮＩドライバ１３０に送信する。このように、複数の解放要求を１つにまとめることで、解放要求の出力頻度を低下させ、ステアリング解放処理の効率を向上させることができる。しかも解放候補が一定数に達したときに解放処理を行うため、多数のプロセスが並列実行された場合であっても、ステアリング記憶部６０の空き容量が枯渇する前に、不使用のステアリングの記憶領域を一斉解放できる。

また第２の実施の形態では、解放候補は、プロセスから依頼された順番に登録され、一斉に解放されるときには古い候補から一定の範囲内の解放候補について、ステアリングの記憶領域を解放するようにする。これにより、新しく候補となったＳＴａｇは登録解除されずに保持される。すなわち、使用しなくなってからの期間が短いバッファは、長期間不使用のままのバッファに比べて再利用される可能性が高いため、対応するステアリングの解放の対象から除外される。これにより、使用頻度の高いＳＴａｇが登録解除されることが抑止され、再登録処理の多発による処理効率の低下が抑止される。また、解放候補として蓄積するＳＴａｇの数を最適に調整することで、登録解除の回数を減らし、登録解除が頻繁に発生することによるオーバーヘッドが抑止できる。

また第２の実施の形態では、ステアリング記憶部６０の空き容量が枯渇しそうになったときにも、ＳＴａｇの登録解除を行う。これにより、ステアリング記憶部６０の空き容量が枯渇することが、より確実に抑止できる。

図８は、ＳＴａｇの一斉解放の管理を行うために通信管理部が保持する情報を示す図である。通信管理部１２０は、使用状況管理テーブル１２１、解放候補リスト１２２、および解放リスト１２３を、ユーザ空間のメモリに格納する。

使用状況管理テーブル１２１は、ＳＴａｇに対応するバッファの使用状況を関するデータテーブルである。使用状況管理テーブル１２１には、ＳＴａｇの値に対応付けて、使用中カウンタの値が設定される。使用中カウンタは、ＳＴａｇが使用されるごとに１ずつカウントアップされ、使用が終了するごとに１ずつカウントダウンされる。使用中カウンタの値が「０」のＳＴａｇは、使用が終了している。

解放候補リスト１２２は、解放候補のＳＴａｇのリストである。バッファを用いたプロセス間通信のデータ転送が完了するごとに、そのバッファに対応するＳＴａｇの値が、解放候補リスト１２２に登録される。解放候補リスト１２２は、例えば上位に登録されているＳＴａｇほど、古い（解放候補になってからの時間が長い）解放候補である。

解放リスト１２３は、一斉解放を行う際に、実行対象となるＳＴａｇのリストである。解放リスト１２３に登録されているすべてのＳＴａｇを指定した解放要求がＮＩドライバ１３０に送信されることで、複数のＳＴａｇが一斉に解放される。

次に、通信管理部１２０における、ＮＩドライバ１３０へのＳＴａｇ問い合わせ処理について説明する。
図９は、ＳＴａｇ問い合わせ処理の手順の一例を示すフローチャートである。

［ステップＳ１０１］通信管理部１２０は、プロセスからの、データ送受信用のバッファに対応付けられたＳＴａｇの問い合わせ要求を、ＭＰＩ１１０を介して受信する。問い合わせ要求には、例えばバッファの仮想アドレスが含まれる。

［ステップＳ１０２］通信管理部１２０は、ステアリング記憶部６０から、問い合わせ要求に示されたバッファに対応するステアリングを、ステアリング記憶部６０から検索する。例えば通信管理部１２０は、ステアリング記憶部６０内の各ステアリングのメモリブロック仮想アドレスと、問い合わせ要求に示された仮想アドレスとを比較し、一致するステアリングを検索する。

［ステップＳ１０３］通信管理部１２０は、該当ステアリングがあれば、処理をステップＳ１０５に進める。該当ステアリングがなければ、処理をステップＳ１０４に進める。
［ステップＳ１０４］通信管理部１２０は、ＮＩドライバ１３０へ、ＳＴａｇの割り当てを依頼する。するとＮＩドライバ１３０において、ステアリング記憶部６０内の不使用のステアリングが、問い合わせ要求で示されたバッファ用に割り当てられ、そのステアリングにＳＴａｇが割り当てられる。割り当てられたＳＴａｇが、ＮＩドライバ１３０から通信管理部１２０に送信される。なお、ＳＴａｇを割り当てたステアリングには、問い合わせ要求の出力元のプロセスが確保したバッファの記憶領域に関する情報が設定される。

［ステップＳ１０５］通信管理部１２０は、使用状況管理テーブル１２１の、問い合わせ要求にバッファのＳＴａｇの使用中カウンタに、１を加算する。
［ステップＳ１０６］通信管理部１２０は、ＭＰＩによる問い合わせ要求への応答として、ＳＴａｇを返す。

このように、バッファに対応するＳＴａｇの問い合わせがあると、そのＳＴａｇの使用済カウンタがカウントアップされる。
次に、ＳＴａｇの登録解除手順について説明する。ＳＴａｇの登録解除を実行するタイミングには、解放候補が所定数以上蓄積された場合と、使用できるステアリングが枯渇した場合とがある。以下、それぞれの場合の処理手順について説明する。

図１０は、ＳＴａｇの登録解除処理手順の第１の例を示すフローチャートである。第１の例は、解放候補が所定数以上蓄積された場合にＳＴａｇの登録解除を行うものである。
［ステップＳ１１１］通信管理部１２０は、プロセスからの、ＳＴａｇを指定した解放要求を、ＭＰＩ１１０を介して受信する。

［ステップＳ１１２］通信管理部１２０は、解放要求に示されたＳＴａｇが、解放候補か否かを判断する。例えば通信管理部１２０は、解放要求に示されたＳＴａｇを、解放候補リスト１２２から検索する。解放候補リスト１２２に該当するＳＴａｇがあれば、そのＳＴａｇは既に解放候補になっていると判断される。解放候補であれば、処理がステップＳ１１３に進められる。解放候補でなければ、処理がステップＳ１１４に進められる。

［ステップＳ１１３］通信管理部１２０は、解放候補リスト１２２内の該当する解放候補のＳＴａｇを、最新の解放候補となる位置に移動する。このような解放候補の移動は、同じＳＴａｇを指定した解放要求が複数回出力された場合、最後の解放要求に応じたＳＴａｇのみを解放候補リスト１２２に残すことと同じである。その後、処理がステップＳ１１５に進められる。

［ステップＳ１１４］通信管理部１２０は、解放要求に示されたＳＴａｇを、最新の解放候補として解放候補リスト１２２に登録する。
［ステップＳ１１５］通信管理部１２０は、使用状況管理テーブル１２１における、解放要求に示されたＳＴａｇの使用中カウンタの値を、１だけ減算する。

［ステップＳ１１６］通信管理部１２０は、ＳＴａｇの使用中カウンタの値が「０」になったか否かを判断する。使用中カウンタの値が「０」であれば、そのＳＴａｇに対応するステアリングが使用されていない。使用中カウンタの値が「０」であれば、処理がステップＳ１１７に進められる。使用中カウンタの値が「０」でなければ、ＳＴａｇ解放処理が終了する。

［ステップＳ１１７］通信管理部１２０は、解放候補リスト１２２内に解放候補として登録されたＳＴａｇの数が所定値（例えば１５０）以上か否かを判断する。解放候補の数が所定値以上であれば、処理がステップＳ１１８に進められる。解放候補の数が所定値未満であれば、ＳＴａｇ解放処理が終了する。

［ステップＳ１１８］通信管理部１２０は、ステップＳ１１９〜Ｓ１２１の処理の繰り返し回数をカウントし、該当処理を例えば１００回繰り返す。
［ステップＳ１１９］通信管理部１２０は、解放候補リスト１２２内の解放候補を、古い方から順に選択する。

［ステップＳ１２０］通信管理部１２０は、使用状況管理テーブル１２１を参照し、選択した解放候補（ＳＴａｇ）の使用中カウンタの値が「０」か否かを判断する。使用中カウンタの値が「０」であれば、処理がステップＳ１２１に進められる。使用中カウンタの値が「０」でなければ、その解放候補に対応するステアリングが再利用されているため、解放候補のまま保留として、処理がステップＳ１２２に進められる。

［ステップＳ１２１］通信管理部１２０は、選択したＳＴａｇを、解放リスト１２３に登録すると共に解放候補リスト１２２から削除する。
［ステップＳ１２２］通信管理部１２０は、ステップＳ１１９〜Ｓ１２１の処理の１００回の繰り返しが完了したら、処理をステップＳ１２３に進める。繰り返し回数が１００回に達していなければ、ステップＳ１１９〜Ｓ１２１の処理が繰り返される。

［ステップＳ１２３］通信管理部１２０は、解放リスト１２３に登録されているＳＴａｇの一斉の解放要求を、ＮＩドライバ１３０に送信する。
［ステップＳ１２４］解放要求に応じて、ＮＩドライバ１３０が、解放リスト１２３に登録されているＳＴａｇの登録を一斉に解除する。すなわち、登録解除されたＳＴａｇが付与されたステアリングも同時に登録解除され、そのステアリングが格納されていた記憶領域が解放される。解放された記憶領域は、空き領域として扱われる。ＮＩドライバ１３０は、解放できなかったＳＴａｇがある場合、そのＳＴａｇを通信管理部１２０に通知する。

［ステップＳ１２５］通信管理部１２０は、解放できなかったＳＴａｇを解放候補として解放候補リスト１２２に登録する。この際、解放リスト１２３に登録されているＳＴａｇは、すべて削除される。

このようにして、解放候補が所定数以上蓄積されたときに、複数のＳＴａｇをまとめて、対応するステアリングの記憶領域の解放を依頼することができる。これにより、ＮＩドライバ１３０への解放要求の送信頻度を少なくすることができ、ステアリングの記憶領域の解放に要する処理の効率化を図ることができる。

図１１は、ＳＴａｇの登録解除処理手順の第２の例を示すフローチャートである。第２の例は、解放候補が所定数以上蓄積された場合にＳＴａｇの登録解除を行うものである。図１１に示す処理のうち、ステップＳ１３２〜Ｓ１３９の処理は、図１０に示すステップＳ１１８〜Ｓ１２５と同様である。異なるのは、ステップＳ１３１のみである。

［ステップＳ１３１］通信管理部１２０は、ステアリング記憶部６０の空き領域の枯渇のおそれを検知する。例えば通信管理部１２０は、新たに使用できるステアリングの数を、定期的に確認する。予めステアリングの最大数が決まっていれば、その最大数と、現在ＳＴａｇが付与されているステアリング数との差分が、新たに使用できるステアリングの数である。通信管理部１２０は、新たに使用できるステアリングの数が所定値以下であれば、使用できるステアリングの枯渇のおそれがあると判断する。通信管理部１２０は、新たに使用できるステアリングの枯渇のおそれがあると判断した場合、以下のステップＳ１３２〜Ｓ１３９の処理を実行する。

このようにして、ステアリング記憶部６０の空き領域が枯渇する前に、複数のＳＴａｇをまとめて登録解除を依頼し、すでに存在するステアリングが格納されている記憶領域を解放することができる。例えば解放候補が少ない（１５０未満）状況でも、ステアリングの獲得処理が頻発し、ステアリング記憶部６０の空き領域が不足気味になれば、その時点で不使用となっているステアリングの登録が解除し、記憶領域が解放される。これにより、ステアリング記憶部６０の空き領域が枯渇し、新たなステアリングを設定できなくなることを抑止できる。

以上のようにして、複数の解放要求を１つにまとめてＯＳ内のＮＩドライバに送信することができ、解放要求の送信回数を削減できる。解放要求の送信回数を削減できれば、解放要求に伴うオーバーヘッドが削減され、プロセス間通信の処理効率が向上する。

例えば、ＳＴａｇの登録解除にかかる時間は、システムコールとハードアクセスの時間で一回あたり４〜５μ秒のオーバーヘッドがかかる。それに対し、一対一通信が実行される時間は１μ秒程度であり、通信のたびにＳＴａｇの登録解除を行うと通信の４〜５倍も大きなオーバーヘッドとなってしまう。解放候補が１５０個蓄積されるまでには、一対一通信が１５０回行われている。１５０回分の通信時間は、１μ秒×１５０回＝１５０μ秒である。そうすると、プロセス間通信に関する処理全体に対する登録解除時間の影響は、２〜４％程度まで縮小される。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ 第１解放要求
２ 第２解放要求
１０ 並列演算装置
１１ 記憶部
１２ 演算部
１３ａ，１３ｂ，１３ｃ，・・・ プロセス
１４ａ，１４ｂ，１４ｃ，・・・ バッファ
１５ 解放候補リスト
１６ プロセス間通信管理部
１７ ＯＳ
１８ 管理情報記憶領域
１８ａ，１８ｂ，１８ｃ，・・・ 管理情報
１９ａ，１９ｂ，１９ｃ，・・・ 識別子

Claims (7)

1. コンピュータに、
   プロセス間通信対象のデータを格納するバッファの管理情報を記憶する記憶領域の解放を要求する第１解放要求が出力されるごとに、前記第１解放要求を蓄積し、
   蓄積された前記第１解放要求の数が閾値に達すると、蓄積された前記第１解放要求のうちの少なくとも一部を、実行対象の第１解放要求として選択し、
   前記実行対象の第１解放要求に示されている管理情報の記憶領域の解放をまとめて要求する第２解放要求を出力する、
   処理を実行させるプロセス間通信プログラム。
2. 前記選択では、現在再利用されていない管理情報の記憶領域の解放を要求する前記第１解放要求を、前記実行対象の第１解放要求として選択する請求項１記載のプロセス間通信プログラム。
3. 前記選択では、出力時期が古い方から所定数の前記第１解放要求の中から、前記実行対象の第１解放要求を選択する請求項１または２記載のプロセス間通信プログラム。
4. 前記第１解放要求の蓄積では、同一の管理情報に関する前記第１解放要求が複数出力された場合、最後に出力された前記第１解放要求のみを蓄積する請求項１乃至３のいずれかに記載のプロセス間通信プログラム。
5. 前記コンピュータに、さらに、
   管理情報を記憶するための空き領域が所定値以下になると、蓄積された前記第１解放要求のうちの少なくとも一部を、前記実行対象の第１解放要求として選択する処理を実行させる請求項１乃至４のいずれかに記載のプロセス間通信プログラム。
6. コンピュータが、
   プロセス間通信対象のデータを格納するバッファの管理情報を記憶する記憶領域の解放を要求する第１解放要求が出力されるごとに、前記第１解放要求を蓄積し、
   蓄積された前記第１解放要求の数が閾値に達すると、蓄積された前記第１解放要求のうちの少なくとも一部を、実行対象の第１解放要求として選択し、
   前記実行対象の第１解放要求に示されている管理情報の記憶領域の解放をまとめて要求する第２解放要求を出力する、
   解放要求方法。
7. プロセス間通信対象のデータを格納するバッファの管理情報を記憶する記憶部と、
   管理情報を記憶する記憶領域の解放を要求する第１解放要求が出力されるごとに、前記第１解放要求を蓄積し、蓄積された前記第１解放要求の数が閾値に達すると、蓄積された前記第１解放要求のうちの少なくとも一部を、実行対象の第１解放要求として選択し、前記実行対象の第１解放要求に示されている管理情報の記憶領域の解放をまとめて要求する第２解放要求を出力する演算部と、
   を有する並列演算装置。

Images