JP6414269B1 - 情報処理装置、情報処理方法および情報処理プログラム - Google Patents

情報処理装置、情報処理方法および情報処理プログラム Download PDF

Info

Publication number
JP6414269B1
JP6414269B1 JP2017082660A JP2017082660A JP6414269B1 JP 6414269 B1 JP6414269 B1 JP 6414269B1 JP 2017082660 A JP2017082660 A JP 2017082660A JP 2017082660 A JP2017082660 A JP 2017082660A JP 6414269 B1 JP6414269 B1 JP 6414269B1
Authority
JP
Japan
Prior art keywords
thread
information processing
data
processing apparatus
threads
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.)
Active
Application number
JP2017082660A
Other languages
English (en)
Other versions
JP2018182628A (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.)
Fujitsu Ltd
Original Assignee
Fujitsu 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 Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2017082660A priority Critical patent/JP6414269B1/ja
Priority to US15/954,111 priority patent/US10318362B2/en
Application granted granted Critical
Publication of JP6414269B1 publication Critical patent/JP6414269B1/ja
Publication of JP2018182628A publication Critical patent/JP2018182628A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/542Event management; Broadcasting; Multicasting; Notifications

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Information Transfer Systems (AREA)

Abstract

【課題】データの受信処理効率を向上させる。【解決手段】制御部2bは、情報処理装置1から、スレッド11〜13のうち送信元スレッドとスレッド21〜23のうち宛先スレッドとの組み合わせを示す識別子が付加されたデータ10を受信すると、受信が完了したことを示す完了通知をキュー25に登録する。また、制御部2bは、キュー25に登録された完了通知を周期的に取り出し、キュー25から完了通知が取り出されたとき、取り出された完了通知に対応する、受信したデータ10を特定し、対応情報24に基づいて、スレッド21〜23のうち、データ10に付加された識別子に対応するコネクションCN1に属するスレッド21を特定し、スレッド21にデータ10を受け渡す。【選択図】図1

Description

本発明は、情報処理装置、情報処理方法および情報処理プログラムに関する。
装置間で通信するためのバスの規格として、InfiniBand(登録商標)が知られている。InfiniBandを用いた通信では、送信側装置と受信側装置のそれぞれにおいて、要求された通信処理が完了したことを示す完了通知が格納されるキューが用いられる。このキューは、CQ(Completion Queue)と呼ばれる。例えば、受信側装置で実行されるスレッドは、データの受信を要求した後、CQのポーリングを行う。要求されたデータが送信側装置から受信されると、完了通知がCQに格納される。スレッドは、ポーリングによってCQから完了通知を取得できたとき、データの受信が完了したことを認識する。
また、InfiniBandに関する技術の例として、受信メッセージにQP(Queue Pair)番号が付加されているかを判定し、付加されている場合だけQP番号のチェックを行うことで、チェック効率を高めた情報処理装置が提案されている。
また、ネットワークインタフェースに関する技術の例として、それぞれRDMA(Remote Direct Memory Access)に対応する主要なNIC(Network Interface Controller)と代替のNICとが共有する待ち行列ペアを作成し、スイッチオーバイベントの検出に応答して、待ち行列ペアの扱いを主要なNICから代替のNICに切り替える方法が提案されている。
特開2015−216450号公報 特表2005−538588号公報
ここで、InfiniBandを用いて、送信側装置で実行される複数のスレッドと、受信側装置で実行される複数のスレッドとの間で通信が行われるケースを想定する。このケースでは、通信を行うスレッドの組み合わせごとにスレッド間のコネクションを確立し、確立されたコネクションごとに前述のCQを用意する方法が、最も単純な方法である。なぜなら、この方法によれば、受信側のスレッドは、自分に対応するCQのポーリングを行うだけで、CQから自分宛ての完了通知を取得できるからである。
しかし、この方法には次のような問題がある。確立されたコネクションの数が多くなるほど、スレッドがデータの受信を要求してから、完了通知をCQから取得するまでの遅延時間が長くなる可能性がある。また、これらのコネクションの間に通信頻度の偏りがある場合、通信頻度が高いコネクションに対応するCQには、上記の遅延時間が長くなったとしても、CQに対して時間当たりに格納される完了通知の数が多くなる。そのため、通信頻度が高いコネクションほど、受信側のスレッドがCQのポーリングを行ったときに完了通知を取得できる確率が高まる。
その反面、通信頻度が低いコネクションほど、受信側のスレッドがCQのポーリングを行ったときに完了通知を取得できる確率が低下する。このように通信頻度が低いコネクション上のスレッドは、完了通知を取得できない無駄なポーリングを多く実行することになる。そのため、プロセッサやメモリなどのリソースが浪費され、処理効率が低いという問題がある。
1つの側面では、本発明は、データの受信処理効率を向上させることが可能な情報処理装置、情報処理方法および情報処理プログラムを提供することを目的とする。
1つの案では、記憶部と制御部とを有する次のような情報処理装置が提供される。記憶部は、情報処理装置で実行される複数のスレッドと、他の情報処理装置で実行される複数のスレッドとの間でコネクションが確立されたスレッドの組み合わせごとに別々に規定される識別子と、組み合わせとの対応関係が登録された対応情報を記憶する。制御部は、他の情報処理装置から、識別子のいずれかに対応する情報が付加されたデータを受信し、受信が完了したことを示す完了通知を、組み合わせごとに確立されるコネクションにおける各々の完了通知の登録のために、情報処理装置で実行される複数のスレッドで共用されるキューに登録する受信処理を実行する。また、制御部は、キューに登録される1以上の完了通知の周期的な確認において、受信したデータに対応する完了通知が確認されてキューから受信したデータに対応する完了通知が取り出された場合に、情報処理装置で実行されるスレッドのうち、受信したデータに付加された情報に基づき対応関係から特定される組み合わせに含まれるスレッドに、受信したデータを受け渡す受信完了処理を実行する。
また、1つの案では、上記の情報処理装置と同様の処理をコンピュータが実行する情報処理方法が提供される。
さらに、1つの案では、上記の情報処理装置と同様の処理をコンピュータに実行させる情報処理プログラムが提供される。
1つの側面では、データの受信処理効率を向上させることができる。
第1の実施の形態に係る情報処理システムの構成例および処理例を示す図である。 第2の実施の形態に係るストレージシステムの構成例を示す図である。 ノードのハードウェア構成例を示す図である。 送信側ノードと受信側ノードとの間の基本的な通信処理手順について説明するための図である。 複数スレッド同士での通信処理の比較例を示す図である。 本実施の形態におけるQP/CQの配置を示す図である。 複数スレッド同士の通信について説明するための図である。 ノードが備える処理機能の構成例を示すブロック図である。 スレッドスケジューリングの第1の比較例を示す図である。 スレッドスケジューリングの第2の比較例を示す図である。 本実施の形態でのスレッドスケジューリングの例を示す図である。 スレッドスケジューリングで使用されるデータ構造の例を示す図である。 キュー間のエントリ移動によるサスペンドおよび起床動作について説明するための図である。 スレッドの状態遷移についての第1の例を示す図である。 スレッドの状態遷移についての第2の例を示す図である。 スレッド間のコネクション確立を要求する処理手順の例を示すフローチャートである。 メッセージの送信を要求する処理手順の例を示すフローチャートである。 メッセージの受信を要求する処理手順の例を示すフローチャート(その1)である。 メッセージの受信を要求する処理手順の例を示すフローチャート(その2)である。 メッセージの受信を要求する処理手順の例を示すフローチャート(その3)である。 スレッドスケジューラの処理手順の例を示すフローチャート(その1)である。 スレッドスケジューラの処理手順の例を示すフローチャート(その2)である。 スレッドの処理例を示す図である。
以下、本発明の実施の形態について図面を参照して説明する。
〔第1の実施の形態〕
図1は、第1の実施の形態に係る情報処理システムの構成例および処理例を示す図である。図1に示す情報処理システムは、情報処理装置1,2を有する。情報処理装置1と情報処理装置2との間は、例えば、InfiniBandによって接続されている。そして、情報処理装置1と情報処理装置2とは、互いに通信することが可能になっている。
情報処理装置1では、スレッド11〜13が実行される。一方、情報処理装置2では、スレッド21〜23が実行される。そして、スレッド11とスレッド21との間でコネクションCN1が確立されており、コネクションCN1を介してスレッド11とスレッド21との通信が行われる。また、スレッド12とスレッド22との間でコネクションCN2が確立されており、コネクションCN2を介してスレッド12とスレッド22との通信が行われる。さらに、スレッド13とスレッド23との間でコネクションCN3が確立されており、コネクションCN3を介してスレッド13とスレッド23との通信が行われる。
以下、情報処理装置1から情報処理装置2に対してデータが送信される場合について説明する。
受信側の情報処理装置2は、記憶部2aと制御部2bとを有する。記憶部2aは、例えば、RAM(Random Access Memory)やHDD(Hard Disk Drive)など、情報処理装置2が備える記憶装置の記憶領域として実現される。制御部2bは、例えば、情報処理装置2が備えるプロセッサとして実現される。
記憶部2aには、対応情報24が記憶されている。対応情報24には、情報処理装置1で実行される複数のスレッドと、情報処理装置2で実行される複数のスレッドとの間でコネクションが確立されたスレッドの組み合わせごとに、固有の識別子が登録されている。図1の例では、スレッド11とスレッド21との間のコネクションCN1に対して、識別子「00」が登録されている。また、スレッド12とスレッド22との間のコネクションCN2に対して、識別子「01」が登録されている。さらに、スレッド13とスレッド23との間のコネクションCN3に対して、識別子「02」が登録されている。
また、記憶部2aには、FIFO(First In First Out)方式で情報を格納するキュー25が記憶されている。キュー25には、情報処理装置2のスレッド21〜23のいずれかが、情報処理装置1からのデータの受信を要求し、要求されたデータを情報処理装置1が受信したときに、受信完了を示す完了通知が格納される。ある受信要求に対応する完了通知を制御部2bが取得できたとき、制御部2bは、この受信要求に対応するデータの受信が完了したことを認識できる。
情報処理装置1から情報処理装置2に対しては、確立されたコネクションCN1〜CN3のいずれかを介してデータが送信される。このとき、送信されるデータには、コネクション(すなわち、送信元スレッドと宛先スレッドとの組み合わせ)を示す識別子が付加される。
例えば、スレッド11が、情報処理装置1の通信インタフェース(図示せず)に対してデータの送信を要求することで、コネクションCN1を介してデータ10が送信されたとする。このとき、送信されるデータ10には、コネクションCN1を示す識別子「00」が付加される。一方、スレッド21は、情報処理装置2の通信インタフェース(図示せず)に対してデータの受信を要求し、受信待ち状態になる。
制御部2bは、情報処理装置1からデータ10を受信すると、受信が完了したことを示す完了通知をキュー25に登録する(ステップS1)。その後、制御部2bは、キュー25に登録された完了通知を周期的に取り出す(ステップS2)。
キュー25から完了通知が取り出されると、制御部2bは、取り出された完了通知に対応する受信データを特定し、その受信データに付加された識別子を取得する。制御部2bは、対応情報24を参照し、スレッド21〜23の中から、取得した識別子に対応するコネクションに属するスレッドを特定する。
例えば、取り出された完了通知に対応する受信データとしてデータ10が特定されたとする。この場合、データ10に付加された識別子「00」が取得され、識別子「00」が示すコネクションCN1に属するスレッド21が特定される。すると、制御部2bは、特定されたスレッド21に受信されたデータ10を受け渡す(ステップS3)。これにより、スレッド21は、受信待ち状態から復帰し、データ10を用いて処理を続行できる。
以上の情報処理装置2では、完了通知が格納されるキュー25がスレッド21〜23によって共用される。これとともに、情報処理装置1から送信されるデータに、通信で使用されたコネクションを識別する識別子が付加される。これにより、制御部2bは、キュー25から取得した完了通知に対応する受信データから識別子を取得することで、受信データの宛先がスレッド21〜23のどれであるかを判別可能になる。そして、このように宛先のスレッドを判別可能になることで、1つのキュー25をスレッド21〜23によって共用できるようになる。
キュー25をスレッド21〜23のそれぞれに対して個別に用意せずに、1つだけ用意したことで、キュー25には、1つのコネクションだけでなく、コネクションCN1〜CN3のどれを介して受信されたデータに対応する完了通知も、格納されるようになる。このため、コネクションCN1〜CN3の間で通信頻度に偏りがある場合でも、キュー25に完了通知が格納されている可能性が高くなる。
したがって、制御部2bがキュー25からの完了通知の取り出しを周期的に行ったときに、取り出せる完了通知がキュー25に存在しない可能性が低くなる。その結果、完了通知を取り出せない無駄な取り出し処理が実行される可能性が低減されるので、制御部2bによる受信処理全体の処理効率を向上させることができる。
〔第2の実施の形態〕
図2は、第2の実施の形態に係るストレージシステムの構成例を示す図である。図2に示すストレージシステムは、ノード100−1〜100−4を有する。ノード100−1,100−2,100−3,100−4には、それぞれストレージ200−1,200−2,200−3,200−4が接続されている。そして、ノード100−1,100−2,100−3,100−4は、それぞれストレージ200−1,200−2,200−3,200−4に対するアクセスを制御するストレージ制御装置として動作する。
なお、ストレージ200−1〜200−4のそれぞれには、1台または複数台の不揮発性記憶装置が搭載されている。不揮発性記憶装置は、例えば、SSD(Solid State Drive)やHDD(Hard Disk Drive)である。また、ノード100−1とストレージ200−1、ノード100−2とストレージ200−2、ノード100−3とストレージ200−3、ノード100−4とストレージ200−4は、それぞれストレージノードを形成する。なお、ストレージシステムに含まれるストレージノードの数は、図2のように4ノードに限定されるものではなく、2以上の任意の数とすることができる。
ノード100−1〜100−4は、スイッチ300を介して互いに接続されている。本実施の形態では、ノード100−1〜100−4は、InfiniBandで互いに接続されている。また、ノード100−1〜100−4は、ネットワーク400を介してホスト装置410,420と接続されている。ノード100−1〜100−4とホスト装置410,420との間は、例えば、SAS(Serial Attached SCSI,SCSI:Small Computer System Interface)やFC(Fibre Channel)を用いたSAN(Storage Area Network)によって接続されている。
このストレージシステムは、例えば、ホスト装置410,420から書き込みが要求されたデータが分散して格納される分散ストレージシステムとして動作する。例えば、次のようなストレージアクセス制御が実行される。
ストレージシステムは、ホスト装置410,420に対して複数の論理ボリュームを提供する。ホスト装置410,420は、ある論理ボリュームにアクセスする際、ノード100−1〜100−4のいずれかに対してIO(Input/Output)要求を送信する。また、論理ボリュームにおける書き込みアドレスの範囲ごとに、データの格納を行う担当ノードがあらかじめ決められている。
例えば、あるノードがIO要求として書き込み要求を受信したとする。書き込み要求を受信したノードは、書き込みアドレスを解析して、ノード100−1〜100−4の中から担当ノードを判別し、担当ノードに対して書き込みデータを転送する。担当ノードは、転送された書き込みデータを一旦キャッシュに格納した後、非同期のタイミングで、担当ノードに接続されているストレージに書き込みデータを格納する。
また、例えば、担当ノードは、書き込みデータのハッシュ値に基づいて決められていてもよい。この場合、担当ノードは、書き込みデータのハッシュ値に基づいて、同一内容のデータが重複してストレージに格納されないように制御する「重複除去」を行うこともできる。
なお、ストレージシステムに接続可能なホスト装置の台数は、図2のように2台に限定されるものではない。
図3は、ノードのハードウェア構成例を示す図である。図3に示すノード100は、図2に示したノード100−1〜100−4のいずれかを示す。以下の説明では、ノード100−1〜100−4のそれぞれを特に区別せずに示す場合には、「ノード100」と記載する場合がある。
ノード100は、例えば、図3に示すようなコンピュータとして実現される。ノード100は、CPU(Central Processing Unit)101a〜101c、メモリ102、SSD103、読み取り装置104、ホストインタフェース105、ドライブインタフェース106およびHCA(Host Channel Adapter)107を有する。
CPU101a〜101cは、ノード100全体を統括的に制御する。なお、CPUの個数は3つに限定されるものではない。メモリ102は、DRAM(Dynamic Random Access Memory)などの揮発性記憶装置であり、ノード100の主記憶装置として使用される。メモリ102には、CPU101a〜101cに実行させるOS(Operating System)プログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ102には、CPU101a〜101cによる処理に必要な各種データが格納される。
SSD103は、ノード100の補助記憶装置として使用される。SSD103には、OSプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、HDDなどの他の種類の不揮発性記憶装置が用いられてもよい。読み取り装置104には、可搬型記録媒体104aが脱着される。読み取り装置104は、可搬型記録媒体104aに記録されたデータを読み取ってCPU101a〜101cに送信する。可搬型記録媒体104aとしては、光ディスク、光磁気ディスク、半導体メモリなどがある。
ホストインタフェース105は、ネットワーク400を介してホスト装置410,420との間で通信するためのインタフェース装置である。ドライブインタフェース106は、ストレージ200との間で通信するためのインタフェース装置である。HCA107は、スイッチ300を介して他のノード100と通信するための、InfiniBandに準拠したインタフェース装置である。
以上のハードウェア構成によってノード100(ノード100−1〜100−4)の処理機能を実現することができる。なお、ホスト装置410,420も、ノード100と同様にCPUやメモリなどを有するコンピュータとして実現することができる。
<スレッドに対するキューの割り当て>
次に、ノードで実行されるスレッドに対する、ノード間の通信で用いられるキューの割り当てについて説明する。ここではまず、図4、図5を用いて、InfiniBandを用いたノード間通信の比較例について説明し、その後に本実施の形態におけるノード間通信について説明する。
図4は、送信側ノードと受信側ノードとの間の基本的な通信処理手順について説明するための図である。図4では、HCA511を有するノード510と、HCA521を有するノード520とを示し、ノード510からノード520に対してInfiniBandを介してデータが送信される場合について説明する。
InfiniBandでは、送信用のQP512と、受信用のQP522とを用いて通信が行われる。送信用のQP512は、送信要求を示すエントリを格納するFIFOであり、「SQ(Send Queue)」とも呼ばれる。QP512に格納されるエントリには、例えば、送信メッセージが格納されている送信バッファのアドレスなどが含まれる。また、受信用のQP522は、受信要求を示すエントリを格納するFIFOであり、「RQ(Receive Queue)」とも呼ばれる。QP522に格納されるエントリには、例えば、受信メッセージが格納される受信バッファのアドレスなどが含まれる。
送信側のノード510において、アプリケーション513は、メッセージを送信する際、送信関数「send」(例えば、ibv_post_send())を発行する。すると、送信要求を示すエントリがQP512に格納されるとともに、引数として指定されたアドレスが示す送信バッファに送信メッセージがセットされる。なお、QP512に格納されるエントリはWQE(Work Queue Element)と呼ばれる。HCA511は、QP512から取得したエントリに基づいて送信メッセージを送信する。
また、InfiniBandでは、QPに加えてCQが用いられる。CQは、完了を示すエントリを格納するFIFOである。CQに格納されるエントリは、CQE(Completion Queue Entry)と呼ばれる。このエントリが示す「完了(Completion)」の内容としては、QPのエントリに対応する処理が正常に終了したことを示す「Successful Completion」と、エラーで終了したことを示す「Completion Error」とがある。
HCA511によるメッセージ送信処理が完了すると、完了を示すエントリがCQ514に格納される。アプリケーション513は、送信関数「send」の発行後にCQ514のポーリングを行うことで、送信要求に応じた処理の完了を示すエントリをCQ514から取得する。
一方、受信側のノード520において、アプリケーション523は、メッセージを受信する際、受信関数「recv」(例えば、ibv_post_recv())を発行する。すると、受信要求を示すエントリがQP522に格納される。HCA521は、QP522から取得したエントリに基づいてメッセージを受信し、エントリに含まれるアドレスが示す受信バッファに受信メッセージをセットする。また、HCA521によるメッセージ受信処理が完了すると、完了を示すエントリがCQ524に格納される。アプリケーション523は、受信関数「recv」の発行後にCQ524のポーリングを行うことで、受信要求に応じた処理の完了を示すエントリをCQ524から取得する。アプリケーション523は、取得したエントリに含まれるアドレスが示す受信バッファから、受信メッセージを取得する。
このように、InfiniBandを通じて通信する場合、アプリケーションは、メッセージの送信または受信を要求した後、CQをポーリングすることで、要求した処理が完了したことを検知する。
図5は、複数スレッド同士での通信処理の比較例を示す図である。なお、これ以後、「QP/CQ」とは、送信用のQPと、これに対応するCQと、受信用のQPと、これに対応するCQとを含むものとする。ただし、CQは、送信用のQPと受信用のQPとで共用することも可能である。
ここでは、あるノードで実行される特定のスレッドと、それとは異なるノードで実行される特定のスレッドとの間で通信が行われる場合を想定する。この場合には、一方のノードの1つのスレッドと他方のノードの1つのスレッドとの間で、論定的な通信路であるコネクションを確立し、コネクションごとに個別のQP/CQを割り当てる方法が最も単純な方法である。なぜなら、この方法によれば、各スレッドは、送信や受信を要求した後、割り当てられたCQをポーリングするだけで、自分宛てのエントリを容易に取得できるからである。
例えば図5では、ノード510でスレッド515a〜515dが実行され、ノード520でスレッド525a〜525dが実行されている。そして、スレッド515aとスレッド525aとの間、スレッド515bとスレッド525bとの間、スレッド515cとスレッド525cとの間、スレッド515dとスレッド525dとの間で、それぞれ通信が行われる。
この場合、スレッド515aとスレッド525aとの間のコネクション531aにおいては、スレッド515aに対してQP/CQ516aが割り当てられ、スレッド525aに対してQP/CQ526aが割り当てられる。同様に、スレッド515bとスレッド525bとの間のコネクション531bにおいては、スレッド515bに対してQP/CQ516bが割り当てられ、スレッド525bに対してQP/CQ526bが割り当てられる。また、スレッド515cとスレッド525cとの間にコネクション531cにおいては、スレッド515cに対してQP/CQ516cが割り当てられ、スレッド525cに対してQP/CQ526cが割り当てられる。さらに、スレッド515dとスレッド525dとの間のコネクション531dにおいては、スレッド515dに対してQP/CQ516dが割り当てられ、スレッド525dに対してQP/CQ526dが割り当てられる。
このような構成とすることで、例えば、QP/CQ526aのCQには、スレッド525a宛てのエントリだけが格納される。そのため、スレッド525aは、メッセージの受信を要求した後、QP/CQ526aのCQを監視するだけで、受信要求に対応する完了のエントリを容易に取得できる。
しかしながら、このような構成では、スレッド間で確立されたコネクションの数が多くなった場合に次のような問題がある。
スレッド間で確立されたコネクション531a〜531dは、共通の物理的な通信経路上に存在する。そのため、確立されたコネクションの数が多いほど、スレッドが送信または受信を要求してから、その要求に対応する完了のエントリをCQから取得できるまでの遅延時間が長くなる可能性がある。
また、コネクション531a〜531dの間で通信頻度に偏りがある場合、通信頻度が高いスレッドに対応するCQには、上記の遅延時間が長くなったとしても、CQに対して時間当たりに格納されるエントリの数が多くなる。そのため、通信頻度が高いコネクション上のスレッドほど、CQに対してポーリングしたときに完了のエントリを取得できる確率が高まる。しかし、その一方で、通信頻度が低いコネクション上のスレッドほど、CQに対してポーリングしたときに完了のエントリを取得できる確率が低下する。このように通信頻度が低いコネクション上のスレッドは、無駄なポーリングを多く実行していることになり、CPUやメモリなどのリソースを浪費するという問題がある。
このような問題に対して、本実施の形態では、次の図6のようにQP/CQが配置される。
図6は、本実施の形態におけるQP/CQの配置を示す図である。本実施の形態では、1つのノードは、通信相手のノードごとにQP/CQをそれぞれ1つだけ有する。具体的には、図6に示すように、ノード100−1は、ノード100−2,100−3,100−4とそれぞれ通信するためのQP/CQ111a−1,111b−1,111c−1を有する。ノード100−2は、ノード100−1,100−3,100−4とそれぞれ通信するためのQP/CQ111a−2,111b−2,111c−2を有する。ノード100−3は、ノード100−1,100−2,100−4とそれぞれ通信するためのQP/CQ111a−3,111b−3,111c−3を有する。ノード100−4は、ノード100−1,100−2,100−3とそれぞれ通信するためのQP/CQ111a−4,111b−4,111c−4を有する。
このように、本実施の形態では、1つのノード内で他の1つのノードとの通信で用いられるQP/CQが1つだけに限定される。そして、次の図7に示すように、1つのノードでは、他の1つのノードと通信する複数のスレッドが、1つのQP/CQを共用する。
図7は、複数スレッド同士の通信について説明するための図である。図7では、例として、ノード100−1とノード100−2との間の通信について説明する。また、ノード100−1でスレッド515a〜515dが実行され、ノード100−2でスレッド525a〜525dが実行されるものとする。そして、スレッド515aとスレッド525aとの間、スレッド515bとスレッド525bとの間、スレッド515cとスレッド525cとの間、スレッド515dとスレッド525dとの間で、それぞれ通信が行われるものとする。
ノード100−1は、ノード100−2との通信のためのQP/CQ111a−1を有する。そして、QP/CQ111a−1は、ノード100−2との通信の際にスレッド515a〜515dによって共用される。一方、ノード100−2は、ノード100−1との通信のためのQP/CQ111a−2を有する。そして、QP/CQ111a−2は、ノード100−1との通信の際にスレッド525a〜525dによって共用される。
ただし、この構成では、例えばスレッド525a〜525dからそれぞれ受信要求が発行された場合、QP/CQ111a−2のCQには、スレッド525a〜525dのそれぞれを宛先とする完了のエントリが混在する。このとき、スレッド525a〜525dは、QP/CQ111a−2のCQに格納されたエントリがどのスレッド宛てのものかを判別できない。
そこで、本実施の形態では、スレッド間で確立されたコネクションごとに、システム全体でユニークな識別番号である「XID」が付与される。そして、あるスレッドから他のノードのスレッド宛てにメッセージが送信される際に、それらのスレッド間のコネクションに対応するXIDが送信メッセージに付加される。これにより、受信側ノードのスレッドは、CQから取得したエントリに基づいて受信メッセージを取得したとき、受信メッセージに含まれるXIDから、エントリが自分宛てであるか否かを判別できるようになる。
XIDは、XIDの発行元ノードを示すノード番号と、発行のたびにシーケンシャルに変更される番号とを組み合わせて生成される。XIDが発行元ノード番号を含むことで、他のいずれのノードでも同じXIDが生成されないようにすることができる。なお、後述するように、XIDは、スレッド間のコネクションが確立される際に生成される。「発行元ノード」とは、コネクションの確立を持ちかけたノードを指す。
さらに、本実施の形態では、あるスレッドがポーリングによりCQからエントリを取得したとき、そのエントリが他のスレッド宛てであった場合には、その旨を他のスレッドに認識させることが可能となっている。例えば、スレッド525aがQP/CQ111a−2のCQをポーリングして、受信完了を示すエントリを取得したとき、そのエントリがスレッド525b宛てであった場合には、スレッド525aは、エントリに対応する受信メッセージをスレッド525bに受け渡す。スレッド525bは、その受信メッセージを用いて処理を継続することができる。
以上のように、本実施の形態では、1つのノード内で他の1つのノードとの通信で用いられるCQが1つだけに限定される。また、ノード上のスレッドは、ポーリングによりCQからエントリを取得したとき、そのエントリがどのスレッド宛てのものかをXIDから判別し、宛先のスレッドに対してそのエントリに対応する通信処理の完了を認識させる。
これにより、スレッド間で通信頻度に偏りがある場合でも、各スレッドがCQのポーリングを行ったときに、どのスレッド宛てのエントリも取得できないという確率が低くなる。その結果、無駄なポーリングの回数を減少させることができ、CPUやメモリなどのリソースの利用効率が向上する。また、ノードにおけるリソースの利用効率が向上することで、ホスト装置からのIO要求に対する応答速度を高めることもできる。
なお、QP/CQは、例えば、ストレージシステムの運用を開始した初期段階において、各ノードのメモリ領域に作成される。例えば、各ノードは、他のノードのHCA107のアドレスを指定することでそのHCA107のデバイス情報を取得し、デバイス情報を基に他のノードに対応するQP/CQを作成する。接続されたノード間でQP/CQの作成完了が認識されることで、ノード間の通信が可能になる。
<ノードの処理機能>
図8は、ノードが備える処理機能の構成例を示すブロック図である。ノード100は、記憶部110、アプリケーション120、スレッドスケジューラ131〜133およびHCAドライバ140を有する。
記憶部110は、例えば、メモリ102の記憶領域として実装される。記憶部110には、QP/CQ111a〜111c、XID−Qstr対応テーブル112、コネクションプール113、スレッド−関数対応テーブル114およびReadyキュー115a〜115cが記憶される。
QP/CQ111a〜111cは、他のノードとの通信で使用されるQP/CQである。前述のように、QP/CQ111a〜111cは、それぞれ個別のノードに対応付けられている。
XID−Qstr対応テーブル112は、XIDと待ち合わせ構造体(Q−Structure)との対応関係を保持する。XID−Qstr対応テーブル112には、ノード間のコネクションが確立されて新たなXIDが発行されるたびに、XIDと待ち合わせ構造体を示す情報とを含むレコードが追加登録される。なお、待ち合わせ構造体とは、後述するように、サスペンド状態のスレッドを管理するためのデータ構造体であり、1つのXIDに対して1つ生成される。
コネクションプール113は、未使用のコネクション構造体を保持する。コネクション構造体とは、後述するように、スレッド間のコネクションを介した通信のために使用されるデータ構造体であり、1つのXIDに対して1つ使用される。
スレッド−関数対応テーブル114は、スレッドの処理内容の種別と、その種別のスレッドで実行される関数との対応関係を保持する。
Readyキュー115a〜115cは、実行されるスレッドに対応するエントリを格納するキューである。Readyキュー115a,115b,115cは、それぞれスレッドスケジューラ131,132,133から参照される。
アプリケーション120の処理は、例えば、CPU101a〜101cによって所定のアプリケーションプログラムが実行されることで実現される。アプリケーション120は、例えば、ストレージのアクセス制御処理を実行する。アプリケーション120の処理は、複数のスレッドを含む。
スレッドスケジューラ131〜133およびHCAドライバ140の処理は、例えば、CPU101a〜101cによってOSプログラムが実行されることで実現される。
スレッドスケジューラ131は、Readyキュー115aに基づいて、アプリケーション120のスレッドのうち、CPU101aによって実行されるスレッド121a,121b,・・・の実行順を制御する。スレッドスケジューラ132は、Readyキュー115bに基づいて、アプリケーション120のスレッドのうち、CPU101bによって実行されるスレッド122a,122b,・・・の実行順を制御する。スレッドスケジューラ133は、Readyキュー115cに基づいて、アプリケーション120のスレッドのうち、CPU101cによって実行されるスレッド123a,123b,・・・の実行順を制御する。
HCAドライバ140は、HCA107の動作を制御する。また、HCAドライバ140は、アプリケーション120に対して、HCA107を使用するためのAPI(Application Programming Interface)を提供する。
<CQのポーリングとスレッドスケジューリング>
次に、CQのポーリングとスレッドスケジューリングについて説明する。まず、図9、図10を用いて、スレッドスケジューリングの比較例について説明した後、図11を用いて、本実施の形態のスレッドスケジューリングについて説明する。
図9は、スレッドスケジューリングの第1の比較例を示す図である。図9では例として、スレッドスケジューラ131によるスレッドのスケジューリングについて示す。スレッドスケジューラ131は、Readyキュー115aからエントリを順に取得し、取得したエントリに対応するスレッドの実行を開始させる。スレッドは、ある一定の長さを限度とする処理を実行すると、サスペンドして、制御をスレッドスケジューラ131に移す。
例えば、図9に示すように、スレッドスケジューラ131は、スレッド121aの実行を開始させる。スレッド121aは、処理A1を実行した後、サスペンドして、制御をスレッドスケジューラ131に移す。次に、スレッドスケジューラ131は、スレッド121bの実行を開始させる。スレッド121bは、処理B1を実行した後、サスペンドして、制御をスレッドスケジューラ131に移す。次に、スレッドスケジューラ131は、スレッド121cの実行を開始させる。スレッド121cは、処理C1を実行した後、サスペンドして、制御をスレッドスケジューラ131に移す。次に、スレッドスケジューラ131は、スレッド121aの実行を開始させる。スレッド121aは、処理A1の次の処理A2を実行する。
図10は、スレッドスケジューリングの第2の比較例を示す図である。この図10では、スレッド121a,121bが実行され、スレッド121aによってメッセージの受信処理が行われる場合の例を示す。
まず、スレッドスケジューラ131は、スレッド121aの実行を開始させる(タイミングT11)。スレッド121aは、HCAドライバ140に対して受信関数「recv」を発行する。これにより、受信メッセージに対応するエントリがQPに登録される。また、スレッド121aは、メッセージの受信待ち状態となり、CQに対してポーリングするための関数(ibv_poll_cq)を、受信要求に対応するエントリをCQから取得できるまでの間、一定時間ごとに発行する。しかし、所定回数だけ関数を発行しても対応するエントリを取得できなかった場合、スレッド121aは、一旦サスペンドして、制御をスレッドスケジューラ131に移す(タイミングT12)。
スレッドスケジューラ131は、スレッド121bの実行を開始させる(タイミングT13)。スレッド121bは、処理B1を実行した後、サスペンドして、制御をスレッドスケジューラ131に移す(タイミングT14)。スレッドスケジューラ131は、スレッド121aを起床させる(タイミングT15)。起床したスレッド121aは、ポーリングのための関数の発行を再度繰り返す。しかし、所定回数だけ関数を発行しても対応するエントリを取得できなかった場合、スレッド121aは、サスペンドして、制御をスレッドスケジューラ131に移す(タイミングT16)。
スレッドスケジューラ131は、スレッド121bの実行を開始させる(タイミングT17)。スレッド121bは、処理B1の次の処理B2を実行した後、サスペンドして、制御をスレッドスケジューラ131に移す(タイミングT18)。スレッドスケジューラ131は、スレッド121aを起床させる(タイミングT19)。起床したスレッド121aは、ポーリングのための関数の発行を再度繰り返す。しかし、所定回数だけ関数を発行しても対応するエントリを取得できなかった場合、スレッド121aは、サスペンドして、制御をスレッドスケジューラ131に移す(タイミングT20)。スレッドスケジューラ131は、スレッド121bの実行を開始させ(タイミングT21)、スレッド121bは、処理B2の次の処理B3を実行する。
以上の例のように、受信関数「recv」の発行後に長期間受信メッセージが到着しない場合、スレッド121aは、起床、ポーリング、サスペンドという動作を何度も繰り返すことになる。スレッド121aの起床やサスペンドが行われるたびに、コンテキストスイッチが発生する。コンテキストスイッチは、レジスタのデータ退避などの処理を伴うため、CPUの処理負荷が大きい。このため、上記のようにスレッド121aの起床やサスペンドが繰り返されると、CPUの処理負荷が増大して、実行可能な他のスレッド121bの処理が遅延してしまい、処理効率が低下するという問題がある。
このような問題に対して、本実施の形態では、スレッドだけでなく、スレッドスケジューラもCQのポーリングを実行可能にする。そして、スレッドは、受信関数「recv」の発行後、CQのポーリングを1回だけ実行し、自分宛てのメッセージが到着していない場合にはサスペンドする。このスレッドに対応するエントリを取得するためのポーリングは、それ以後、スレッドスケジューラ(または他のスレッド)によって実行される。
図11は、本実施の形態でのスレッドスケジューリングの例を示す図である。図11では、図10の比較例と同様に、スレッド121a,121bが実行され、スレッド121aによってメッセージの受信処理が行われる場合の例を示す。
まず、スレッドスケジューラ131は、スレッド121aの実行を開始させる(タイミングT31)。スレッド121aは、HCAドライバ140に対して受信関数「recv」を発行し、その後1回だけCQのポーリングを行う。このとき、対応するエントリを取得できなかった場合、スレッド121aは、即座にサスペンドして、制御をスレッドスケジューラ131に移す(タイミングT32)。
一方、スレッドスケジューラ131は、制御が移されるたびに、次に実行させるスレッドのスケジューリングとともに、CQのポーリングを行う。図11の例では、タイミングT32でスレッド121aから制御が移されると、スレッドスケジューラ131は、次に実行させるスレッドとしてスレッド121bを選択するとともに、CQのポーリングを行う。そして、それが終了すると、スレッドスケジューラ131はスレッド121bの実行を開始させる(タイミングT33)。
スレッド121bによる処理B1の実行が終了すると、制御がスレッドスケジューラ131に移り(タイミングT34)、スレッドスケジューラ131によるスケジューリングとポーリングとが行われる。スレッド121aに対応するエントリをCQから取得できない場合、スレッド121bが起床して後続の処理B2を実行する(タイミングT35)。
処理B2の実行が終了すると、制御がスレッドスケジューラ131に移り(タイミングT36)、スレッドスケジューラ131によるスケジューリングとポーリングとが行われる。ここでもスレッド121aに対応するエントリをCQから取得できない場合、スレッド121bが起床して後続の処理B3を実行する(タイミングT37)。
処理B3の実行が終了すると、制御がスレッドスケジューラ131に移り(タイミングT38)、スレッドスケジューラ131によるスケジューリングとポーリングとが行われる。ここで、スレッド121aに対応するエントリをCQから取得できた場合、スレッドスケジューラ131は、スレッド121aを起床させる(タイミングT39)。スレッド121aは、受信メッセージを取得して、後続の処理を再開する。
以上のように、スレッド121aは、受信関数「recv」の発行後、CQのポーリングを1回だけ実行し、対応するエントリを取得できなかった場合にはサスペンドする。このスレッドに対応するエントリを取得するためのポーリングは、それ以後、スレッドスケジューラ131によって実行される。そして、スレッドスケジューラ131によってスレッド121aに対応するエントリがCQから取得された場合、スレッド121aが起床する。
このような処理により、ポーリングに失敗したスレッド121aが起床とサスペンドを何度も繰り返すことが防止される。このため、無駄なコンテキストスイッチの発生回数が少なくなり、CPUの処理負荷が低下する。その結果、CPUの処理効率が向上し、実行可能なスレッド121bの実行遅延を小さくすることができる。
図12は、スレッドスケジューリングで使用されるデータ構造の例を示す図である。本実施の形態では、上記のようなスレッドスケジューリングを実現するための、コネクション構造体151および待ち合わせ構造体152が使用される。
コネクション構造体151は、スレッド間のコネクションが確立されるたびに、そのコネクションの両側のスレッドによってそれぞれ作成され、各スレッドが他方のスレッドとの通信を行うために使用される。コネクション構造体151は、自ノード側スレッド、他ノード側スレッドの各識別番号、XID、QP/CQへのポインタ、および待ち合わせ構造体へのポインタを保持する。
自ノード側スレッドは、コネクションの両側のノードのうち、自ノードのスレッドを示し、他ノード側スレッドは、他ノードのスレッドを示す。XIDは、前述のように、スレッド間のコネクションごとに生成される固有の番号である。QP/CQへのポインタは、通信相手のスレッドとの通信で用いられるQP/CQ111内のQPおよびCQの位置を示す。待ち合わせ構造体へのポインタは、対応する待ち合わせ構造体152の位置を示す。
待ち合わせ構造体152は、自ノード側のスレッドの状態を管理するために使用されるデータ構造体である。待ち合わせ構造体152は、Blockedキュー152aとメッセージ情報キュー152bとを保持する。Blockedキュー152aには、サスペンド状態のスレッドに対応するエントリが、Readyキュー115a〜115cから取り出されて格納される。メッセージ情報キュー152bには、受信メッセージを格納するためのバッファ領域を示すポインタを含むエントリが格納される。
図13は、キュー間のエントリ移動によるサスペンドおよび起床動作について説明するための図である。受信関数「recv」を発行したスレッドは、ポーリングに失敗すると、対応するエントリをReadyキュー115a〜115cのいずれかから取り出し、待ち合わせ構造体152のBlockedキュー152aに格納することで、サスペンド状態に遷移する。このとき、スレッドは、受信メッセージを格納するためのバッファ領域を示すポインタを含むエントリを、待ち合わせ構造体152のメッセージ情報キュー152bに登録する。このバッファ領域は、HCAドライバ140によって受信バッファに格納された受信メッセージを退避するためのメモリ領域である。
その後、スレッドスケジューラまたは他のスレッドによって、受信バッファに格納された受信メッセージがバッファ領域にセットされ、対応するエントリがBlockedキュー152aから取り出され、Readyキュー115a〜115cのいずれかに登録される。これにより、このエントリに対応するスレッドが起床する。
なお、スレッドが起床している状態とは、対応するエントリがReadyキュー1151a〜115cのいずれかに登録されており、そのスレッドが、スレッドスケジューラが次に実行させるスレッドを選択する際の選択対象に含まれている状態を指す。そして、そのエントリがReadyキュー115a〜115cのいずれかからスレッドスケジューラに取り出されることで、そのエントリに対応するスレッドの実行が開始される。
以下、図14、図15を用いて、スレッドの状態遷移の具体例について説明する。図14、図15では、例として、ノード100−1においてスレッド#0とスレッド#1が実行される場合について示す。
図14は、スレッドの状態遷移についての第1の例を示す図である。図14の初期状態では、スレッド#0と、他のノードのスレッド(ここでは、ノード100−2のスレッド#01とする)とのコネクションが確立されている。そして、このコネクションにXID「0」が付与され、XID−Qstr対応テーブル112において、XID「0」に対して待ち合わせ構造体Qstr#0が対応付けられている。また、スレッド#1と、ノード100−2の他のスレッド(スレッド#11とする)とのコネクションが確立されている。そして、このコネクションにXID「1」が付与され、XID−Qstr対応テーブル112において、XID「1」に対して待ち合わせ構造体Qstr#1が対応付けられている。
さらに、スレッド#0は、メッセージの受信を要求した後にサスペンド状態になっており、待ち合わせ構造体Qstr#0のBlockedキュー152aには、スレッド#0に対応するエントリが格納されている。また、待ち合わせ構造体Qstr#0のメッセージ情報キュー152bには、受信メッセージを格納するためのバッファ領域B0を示すポインタを含むエントリが登録されている。
なお、InfiniBandでは、メッセージの送信順序や受信順序は入れ替わらないことが保証されている。
上記状態から、スレッドスケジューラ131が、Readyキュー115aからスレッド#1に対応するエントリを取得し、スレッド#1の実行を開始させたとする(ステップS11)。スレッド#1は、受信関数「recv」をHCAドライバ140に発行して、メッセージの受信を要求する(ステップS12)。これにより、スレッド#1からの受信要求に対応するエントリがQP/CQ111aのQPに格納される。さらに、スレッド#1は、QP/CQ111aのCQに対するポーリングを行う(ステップS13)。
スレッド#1は、CQからエントリE0を取得し、エントリE0が示す受信バッファR0から受信メッセージを取得する。ここで、仮に、取得した受信メッセージがXID「1」を含んでいれば、スレッド#1は、エントリが自分宛てであることを認識し、受信メッセージを用いて後続の処理を実行できる。
しかし、図14の例では、取得した受信メッセージがXID「0」を含んでいたとする。この場合、スレッド#0が受信を要求したメッセージがHCA107によって受信済みであり、その受信メッセージが受信バッファR0に格納されている。スレッド#1は、取得したエントリが自分宛てではないことを認識して、XID−Qstr対応テーブル112を参照し、XID「0」に対応する待ち合わせ構造体Qstr#0を特定する(ステップS14)。
スレッド#1は、待ち合わせ構造体Qstr#0のメッセージ情報キュー152bからエントリを取得し、取得したエントリが示すバッファ領域B0に、受信バッファR0に格納されている受信メッセージを書き込む(ステップS15)。さらに、スレッド#1は、待ち合わせ構造体Qstr#0のBlockedキュー152aからエントリを取り出して、このエントリをReadyキュー115aに移動させる(ステップS16)。これにより、スレッド#0が起床する。すなわち、移動されたエントリがスレッドスケジューラ131に取得されてスレッド#0の実行が開始されたとき、スレッド#0は、バッファ領域B0に書き込まれた受信メッセージを用いて処理を続行できる。
なお、バッファ領域B0は、受信バッファR0に格納された受信メッセージを退避するために用いられる。ステップS13のポーリングが完了することにより、取得されたエントリE0が示す受信バッファR0は解放されてしまう。しかし、受信バッファR0に格納されていた受信メッセージがバッファ領域B0に退避されることで、スレッド#0は、ポーリングの完了後にバッファ領域B0から受信メッセージを取得できるようになる。
スレッド#1は、以上の処理が完了すると、ステップS11でReadyキュー115aから取得されたエントリを、待ち合わせ構造体Qstr#1のBlockedキュー152aに移動させる(ステップS17)。さらに、スレッド#1は、待ち合わせ構造体Qstr#1のメッセージ情報キュー152bに、受信メッセージを格納するためのバッファ領域B1を示すポインタを含むエントリを格納する。これにより、スレッド#1はサスペンドする。
図15は、スレッドの状態遷移についての第2の例を示す図である。図14に示したようにスレッド#1がサスペンドした後に、スレッドスケジューラ131によるQP/CQ111aのCQのポーリングによって、エントリE1が取得される。そして、取得されたエントリE1が示す受信バッファR1から、XID「1」を含む受信メッセージが取得されたとする(ステップS21)。
スレッドスケジューラ131は、XID−Qstr対応テーブル112を参照し、XID「1」に対応する待ち合わせ構造体Qstr#1を特定する(ステップS22)。スレッドスケジューラ131は、待ち合わせ構造体Qstr#1のメッセージ情報キュー152bからエントリを取得し、取得したエントリが示すバッファ領域B1に、受信バッファR1に格納されている受信メッセージを書き込む(ステップS23)。さらに、スレッドスケジューラ131は、待ち合わせ構造体Qstr#1のBlockedキュー152aからエントリを取り出して、このエントリをReadyキュー115aに移動させる(ステップS24)。
これにより、スレッド#1が起床する。すなわち、移動されたエントリがスレッドスケジューラ131に取得されてスレッド#1の実行が開始されたとき、スレッド#1は、バッファ領域B1に書き込まれた受信メッセージを用いて処理を続行できる。
以上の図14、図15の例のように、本実施の形態では、CQのポーリングに1回失敗したスレッドは、それ以上ポーリングを行わずにサスペンドする。その後、スレッドスケジューラまたは他のスレッドによるCQのポーリングにより、サスペンドしたスレッドに対応するエントリがCQから取得されることで、サスペンドしたスレッドが起床する。
このような仕組みにより、ポーリングに失敗してサスペンドしたスレッドは、要求したメッセージが受信されるまで起床しない。そのため、ポーリングに失敗したスレッドがポーリングの再実行のために起床とサスペンドを何度も繰り返すことがなくなり、無駄なコンテキストスイッチの発生回数が減少する。その結果、CPUの処理効率を向上させることができる。
また、上記の仕組みにより、CQに格納されたあるスレッド宛てのエントリは、そのスレッドによるポーリングだけでなく、他のスレッドやスレッドスケジューラによるポーリングによっても取得される。そして、取得されたエントリに対応する受信メッセージを、宛先のスレッドが利用できるようになる。これにより、ポーリングを行ったときに、どのスレッド宛てのエントリも取得できないという確率が低くなる。その結果、無駄なポーリングの回数を減少させることができ、CPUやメモリなどのリソースの利用効率が向上する。
<フローチャート>
次に、ノード100の処理についてフローチャートを用いて説明する。
図16は、スレッド間のコネクション確立を要求する処理手順の例を示すフローチャートである。ここでは例として、ノード100−1のスレッド#11が、ノード100−2のスレッド#21との間でコネクションを確立するケースについて示す。
[ステップS51]スレッド#11は、コネクションプール113から未使用のコネクション構造体151を取得する。このとき、未使用の待ち合わせ構造体152も取得される。スレッド#11は、取得したコネクション構造体151に対して、自ノード側スレッドとしてスレッド#11を登録し、他ノード側スレッドとしてスレッド#21を登録する。また、スレッド#11は、取得したコネクション構造体151に対して、ノード100−2との通信に使用するQP/CQ111aに対するポインタと、取得した待ち合わせ構造体152に対するポインタとを登録する。
さらに、スレッド#11は、新たなXIDを発行して、取得したコネクション構造体151に登録する。XIDは、ノード100−1の番号と、直前に発行されたシーケンシャル番号に「1」を加算した値とを組み合わせることによって算出される。ここでは、説明を簡単にするためにXID「11」が発行されたとする。
[ステップS52]スレッド#11は、発行したXID「11」と、取得した待ち合わせ構造体152を示す情報とを含むレコードを、XID−Qstr対応テーブル112に新たに登録する。
[ステップS53]スレッド#11は、コネクション確立依頼フラグと、通信相手のスレッド#21の種別を示すスレッド種別番号tidと、XID「11」とを、送信バッファにセットする。コネクション確立依頼フラグは、コネクションの確立要求であることを示す「1」にセットされる。
[ステップS54]スレッド#11は、HCAドライバ140に対して送信関数「send」を発行する。このとき、スレッド#11は、引数として、コネクション構造体151へのポインタと、送信バッファのアドレスとをセットする。
これにより、QP/CQ111aのQPに、コネクション確立のための送信要求を示すエントリが登録される。HCAドライバ140は、このエントリを取得すると、送信バッファにセットされた情報をノード100−2に送信する。これにより、新たに発行されたXID「11」が相手のノード100−2に伝達される。
図17は、メッセージの送信を要求する処理手順の例を示すフローチャートである。ここでは例として、図16の処理によってスレッド#21とのコネクションが確立された後に、スレッド#11がスレッド#21に対してメッセージを送信するケースについて示す。
[ステップS61]スレッド#11は、自ノード側スレッドとしてスレッド#11が登録され、他ノード側スレッドとしてスレッド#21が登録されたコネクション構造体151を参照し、このコネクション構造体151からXID「11」を取得する。
[ステップS62]スレッド#11は、コネクション確立依頼フラグと、通信相手のスレッド#21の種別を示すスレッド種別番号tidと、XID「11」とが付加された送信メッセージを、送信バッファにセットする。コネクション確立依頼フラグは、コネクションの確立要求でないことを示す「0」にセットされる。
[ステップS63]スレッド#11は、HCAドライバ140に対して送信関数「send」を発行する。このとき、スレッド#11は、引数として、コネクション構造体151へのポインタと、送信バッファのアドレスとをセットする。
これにより、QP/CQ111aのQPに、メッセージの送信要求を示すエントリが登録される。HCAドライバ140は、このエントリを取得すると、送信バッファにセットされた送信メッセージをノード100−2に送信する。これにより、送信メッセージとともにXID「11」が相手のノード100−2に伝達される。
図18〜図20は、メッセージの受信を要求する処理手順の例を示すフローチャートである。ここでは例として、ノード100−2のスレッド#22が、ノード100−1のスレッド#12から送信されるメッセージを受信するケースについて示す。なお、スレッド#12とスレッド#22との間のコネクションは確立済みであり、このコネクションに対してXID「12」が付与されているものとする。
[ステップS71]スレッド#22は、自ノード側スレッドとしてスレッド#22が登録され、他ノード側スレッドとしてスレッド#12が登録されたコネクション構造体151を参照し、このコネクション構造体151からXID「12」を取得する。
[ステップS72]スレッド#22は、HCAドライバ140に対して受信関数「recv」を発行する。このとき、スレッド#22は、引数として、ステップS71で参照したコネクション構造体151へのポインタと、受信バッファのアドレスとをセットする。
これにより、QP/CQ111aのQPに、メッセージの受信要求を示すエントリが登録される。HCAドライバ140は、このエントリを取得すると、ノード100−2からメッセージを受信して受信バッファにセットする。そして、HCAドライバ140は、QP/CQ111aのCQに、受信完了を示すエントリを登録する。ただし、次のステップS73の実行時点では、このエントリがCQに登録されているとは限らない。
[ステップS73]スレッド#22は、HCAドライバ140に対して、ノード100−1との通信用のCQ、すなわち、QP/CQ111aのCQにポーリングするための関数を発行する。これにより、CQのポーリングが行われる。
[ステップS74]スレッド#22は、ポーリングの結果として、受信完了を示すエントリをCQから取得できたかを判定する。スレッド#22は、該当エントリを取得できた場合、図19のステップS81の処理を実行し、取得できなかった場合、ステップS75の処理を実行する。
なお、ステップS74で取得されるエントリは、ステップS72による受信要求に対応する受信完了を示すとは限らない。
また、ステップS74では、送信完了を示すエントリが取得される場合もある。この場合、スレッド#22は、送信要求を行ったスレッドを起床させた後、ステップS75の処理を実行する。
[ステップS75]スレッド#22は、Readyキューからスレッドスケジューラによって取得された、スレッド#22に対応するエントリを、待ち合わせ構造体152のBlockedキュー152aに移動させる。移動先の待ち合わせ構造体152は、ステップS71で参照されたコネクション構造体151に登録されたポインタによって示される待ち合わせ構造体152である。
また、スレッド#22は、この待ち合わせ構造体152のメッセージ情報キュー152bに、受信メッセージを格納するためのバッファ領域を示すポインタを含むエントリを格納する。以上のステップS75の処理により、スレッド#22はサスペンド状態に遷移する。
以下、図19を用いて説明を続ける。
[ステップS81]スレッド#22は、HCAドライバ140によって受信されたメッセージが格納されている受信バッファから、ステップS74で取得されたエントリに対応する受信メッセージを取得する。スレッド#22は、受信メッセージから、コネクション確立依頼フラグと、スレッド種別番号tidと、XIDとを取得する。
[ステップS82]スレッド#22は、コネクション確立依頼フラグが「1」の場合、ステップS83の処理を実行し、「0」の場合、図20のステップS91の処理を実行する。
[ステップS83]コネクション確立依頼フラグが「1」の場合、スレッド間のコネクションを新たに確立することが要求されている。ここでは例として、図16の処理によってスレッド#11とスレッド#21との間のコネクションの確立が要求されたものとして説明する。この場合、受信メッセージにはXID「11」が含まれている。
スレッド#22は、まず、待ち合わせ構造体152を新たに作成する。
[ステップS84]スレッド#22は、受信メッセージから取得したXID「11」と、ステップS83で作成した待ち合わせ構造体152を示すポインタとを含むレコードを、XID−Qstr対応テーブル112に対して新たに登録する。
[ステップS85]スレッド#22は、スレッド−関数対応テーブル114を参照し、受信メッセージから取得したスレッド種別番号tidに対応付けられたスレッド#21を特定する。スレッド#22は、特定されたスレッド#21を起動する。この後、スレッド#22は、図18のステップS75の処理を実行して、サスペンド状態に遷移する。
[ステップS86]ステップS85で起動したスレッド#21は、コネクションプール113から未使用のコネクション構造体151を取得する。スレッド#21は、取得したコネクション構造体151に対して、自ノード側スレッドとしてスレッド#21を登録し、他ノード側スレッドとしてスレッド#11を登録する。また、スレッド#21は、取得したコネクション構造体151に対して、ステップS81で受信メッセージから取得したXIDを登録する。さらに、スレッド#21は、ノード100−1との通信に使用するQP/CQ111aに対するポインタと、ステップS83で作成された待ち合わせ構造体152に対するポインタとを登録する。これにより、スレッド#11とスレッド#21とのコネクションが確立される。
なお、この後、起動したスレッド#21は、スレッドスケジューラの制御の下で後続の処理を実行する。
以下、図20を用いて説明を続ける。
[ステップS91]図19のステップS82でコネクション確立依頼フラグが「0」の場合、CQから取得されたエントリは受信完了を示すエントリである。スレッド#22は、受信メッセージから取得したXIDが、図18のステップS71で取得したXID「12」と一致するかを判定する。XIDが一致した場合、CQから取得されたエントリはスレッド#22宛てのエントリである。この場合、スレッド#22は、ステップS92の処理を実行する。一方、XIDが一致しない場合、CQから取得されたエントリはスレッド#22以外の他のスレッド宛てのエントリである。この場合、スレッド#22は、ステップS93の処理を実行する。
[ステップS92]スレッド#22は、取得した受信メッセージを用いて後続の処理を実行する。
[ステップS93]スレッド#22は、XID−Qstr対応テーブル112を参照し、受信メッセージから取得したXIDに対応する待ち合わせ構造体152を特定する。
[ステップS94]スレッド#22は、特定された待ち合わせ構造体152のメッセージ情報キュー152bからエントリを取得し、取得したエントリが示すバッファ領域に受信メッセージを書き込む。さらに、スレッド#22は、この待ち合わせ構造体152のBlockedキュー152aからエントリを取り出して、このエントリをReadyキューに移動させる。CQから取得されたエントリが、例えばスレッド#23宛てであったとすると、ステップS94の処理により、スレッド#23が起床する。
スレッド#22は、この後、図18のステップS75の処理を実行して、サスペンド状態に遷移する。
図21、図22は、スレッドスケジューラの処理手順の例を示すフローチャートである。ここでは例として、ノード100−2のスレッドスケジューラ131の処理について示す。なお、図21、図22の処理は、繰り返し実行される。
[ステップS101]スレッドスケジューラ131は、ノード100−2のCQの中にポーリングしていないCQがあるかを判定する。スレッドスケジューラ131は、ポーリングしていないCQがある場合、ステップS102の処理を実行し、すべてのCQについてポーリング済みである場合、ステップS104の処理を実行する。
[ステップS102]スレッドスケジューラ131は、ポーリングしていないCQに対してポーリングを行う。
[ステップS103]スレッドスケジューラ131は、ポーリングの結果として、受信完了を示すエントリをCQから取得できたかを判定する。スレッドスケジューラ131は、該当エントリを取得できた場合、図22のステップS111の処理を実行し、取得できなかった場合、ステップS101の処理を実行する。
[ステップS104]スレッドスケジューラ131は、Readyキュー115aから先頭のエントリを取得し、そのエントリに対応するスレッドの実行を開始させる。
以下、図22を用いて説明を続ける。
[ステップS111]スレッドスケジューラ131は、HCAドライバ140によって受信されたメッセージが格納されている受信バッファから、図21のステップS103で取得されたエントリに対応する受信メッセージを取得する。スレッドスケジューラ131は、受信メッセージから、コネクション確立依頼フラグと、スレッド種別番号tidと、XIDとを取得する。
[ステップS112]スレッドスケジューラ131は、コネクション確立依頼フラグが「1」の場合、ステップS113の処理を実行し、「0」の場合、ステップS116の処理を実行する。
[ステップS113]コネクション確立依頼フラグが「1」の場合、スレッド間のコネクションを新たに確立することが要求されている。ここでは例として、図16の処理によってスレッド#11とスレッド#21との間のコネクションの確立が要求されたものとして説明する。この場合、受信メッセージにはXID「11」が含まれている。
スレッドスケジューラ131は、まず、待ち合わせ構造体152を新たに作成する。
[ステップS114]スレッドスケジューラ131は、受信メッセージから取得したXID「11」と、ステップS113で作成した待ち合わせ構造体152を示すポインタとを含むレコードを、XID−Qstr対応テーブル112に対して新たに登録する。
[ステップS115]スレッドスケジューラ131は、スレッド−関数対応テーブル114を参照し、受信メッセージから取得したスレッド種別番号tidに対応付けられたスレッド#21を特定する。スレッドスケジューラ131は、特定されたスレッド#21を起動する。この後、スレッドスケジューラ131は、図21のステップS101の処理を実行する。
[ステップS116]スレッドスケジューラ131は、XID−Qstr対応テーブル112を参照し、受信メッセージから取得したXIDに対応する待ち合わせ構造体152を特定する。
[ステップS117]スレッドスケジューラ131は、特定された待ち合わせ構造体152のメッセージ情報キュー152bからエントリを取得し、取得したエントリが示すバッファ領域に受信メッセージを書き込む。さらに、スレッドスケジューラ131は、この待ち合わせ構造体152のBlockedキュー152aからエントリを取り出して、このエントリをReadyキューに移動させる。CQから取得されたエントリが、例えばスレッド#23宛てであったとすると、ステップS117の処理により、スレッド#23が起床する。
この後、スレッドスケジューラ131は、図21のステップS101の処理を実行する。
<スレッドの具体例>
次に、スレッドの具体的な処理例について説明する。
図23は、スレッドの処理例を示す図である。図23の例では、ノード100−1のスレッド#15と、ノード100−2のスレッド#25との間でコネクションが確立されているものとする。スレッド#15は、ホスト装置からの書き込み要求を受け付けるスレッドであり、スレッド#25は、書き込みデータの格納を担当する「担当ノード」において、他のノードから転送された書き込みデータを受け付けるスレッドである。
[ステップS121]スレッド#15は、ホスト装置から、書き込み要求および書き込みデータを受信する。
[ステップS122]スレッド#15は、書き込みアドレスを解析して、ノード100−2を担当ノードと判別する。
[ステップS123]スレッド#15は、担当ノードであるノード100−2に対して書き込みデータを送信する。
[ステップS124]スレッド#25は、書き込みデータを受信する。
[ステップS125]スレッド#25は、受信した書き込みデータをキャッシュに書き込む。
[ステップS126]スレッド#25は、書き込みの完了通知をノード100−1に送信する。
[ステップS127]スレッド#15は、完了通知を受信し、ホスト装置に対して書き込みが完了したことを通知する。
[ステップS128]スレッド#15は、次の書き込みデータの受信待ち状態になる。
以上の処理において、スレッド#25は、例えば、ステップS124で書き込みデータを受信するために受信関数「recv」を発行し、続いてCQをポーリングする。スレッド#25は、ポーリングにより自分宛てのエントリを取得できなかった場合、サスペンドして受信待ち状態となる。その後、スレッド#15とスレッド#25とのコネクションに対応するXIDが付加された書き込みデータが受信されると、ノード100−2上の他のスレッドまたはスレッドスケジューラによるポーリングによって、CQからスレッド#25宛てのエントリが取得される。すると、スレッド#25は起床し、受信された書き込みデータを取得して、ステップS125からの後続処理の実行を開始する。
このような処理により、スレッド#25は、ポーリングによる書き込みデータの取得に失敗するとサスペンドし、書き込みデータの受信が完了するまで起床しない。このため、スレッド#25のサスペンドおよび起床の回数が低減されて、コンテキストスイッチの発生が抑制され、その結果、ノード100−2のCPUの利用効率が向上される。
一方、スレッド#15は、例えば、ステップS123の書き込みデータ送信が完了した後、ステップS127で完了通知を受信するために受信関数「recv」を発行し、続いてCQをポーリングする。スレッド#15は、ポーリングにより自分宛てのエントリを取得できなかった場合、サスペンドして受信待ち状態となる。その後、スレッド#15とスレッド#25とのコネクションに対応するXIDが付加された完了通知が受信されると、ノード100−1上の他のスレッドまたはスレッドスケジューラによるポーリングによって、CQからスレッド#15宛てのエントリが取得される。すると、スレッド#15は起床し、受信された完了通知を取得して、ステップS128からの後続処理の実行を開始する。
このような処理により、スレッド#15は、ポーリングによる完了通知の取得に失敗するとサスペンドし、完了通知の受信が完了するまで起床しない。このため、スレッド#15のサスペンドおよび起床の回数が低減されて、コンテキストスイッチの発生が抑制され、その結果、ノード100−1のCPUの利用効率が向上される。
なお、上記の各実施の形態に示した装置(例えば、情報処理装置1,2、ノード100,100−1〜100−4)の処理機能は、コンピュータによって実現することができる。その場合、各装置が有すべき機能の処理内容を記述したプログラムが提供され、そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置(HDD)、フレキシブルディスク(FD)、磁気テープなどがある。光ディスクには、DVD(Digital Versatile Disc)、DVD−RAM、CD−ROM(Compact Disc-Read Only Memory)、CD−R(Recordable)/RW(ReWritable)などがある。光磁気記録媒体には、MO(Magneto-Optical disk)などがある。
プログラムを流通させる場合には、例えば、そのプログラムが記録されたDVD、CD−ROMなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムまたはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムにしたがった処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムにしたがった処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムにしたがった処理を実行することもできる。
1,2 情報処理装置
2a 記憶部
2b 制御部
10 データ
11〜13,21〜23 スレッド
24 対応情報
25 キュー
CN1〜CN3 コネクション
S1〜S3 ステップ

Claims (7)

  1. 情報処理装置において、
    前記情報処理装置で実行される複数のスレッドと、他の情報処理装置で実行される複数のスレッドとの間でコネクションが確立されたスレッドの組み合わせごとに別々に規定される識別子と、前記組み合わせとの対応関係が登録された対応情報を記憶する記憶部と、
    前記他の情報処理装置から、前記識別子のいずれかに対応する情報が付加されたデータを受信し、受信が完了したことを示す完了通知を、前記組み合わせごとに確立される前記コネクションにおける各々の完了通知の登録のために前記情報処理装置で実行される複数のスレッドで共用されるキューに登録する受信処理と、
    前記キューに登録される1以上の完了通知の周期的な確認において、前記受信したデータに対応する完了通知が確認されて前記キューから前記受信したデータに対応する完了通知が取り出された場合に、前記情報処理装置で実行されるスレッドのうち、前記受信したデータに付加された前記情報に基づき前記対応関係から特定される前記組み合わせに含まれるスレッドに、前記受信したデータを受け渡す受信完了処理と、
    を実行する制御部と、
    を有する情報処理装置。
  2. 前記受信完了処理は、
    前記情報処理装置で実行されるスレッドのうち第のスレッドによって、前記他の情報処理装置で実行されるスレッドのうち第のスレッドを送信元とするデータの受信が要求された後、前記キューから完了通知を取り出し、当該完了通知に対応する、前記他の情報処理装置から受信した第1の受信データを特定し、前記第1の受信データに付加された、前記識別子のいずれかに対応する付加情報が、前記第のスレッドと前記第のスレッドとの組み合わせに対応する前記識別子と一致しない場合には、前記第のスレッドを待機状態に遷移させる第1の受信要求処理と、
    前記情報処理装置で実行されるスレッドのうち第のスレッドによって、前記他の情報処理装置で実行されるスレッドのうち第のスレッドを送信元とするデータの受信が要求された後、前記キューから完了通知を取り出し、当該完了通知に対応する、前記他の情報処理装置から受信した第2の受信データを特定し、前記第2の受信データに付加された、前記識別子のいずれかに対応する付加情報が、前記第のスレッドと前記第のスレッドとの組み合わせに対応する前記識別子と一致する場合には、前記第のスレッドに前記第2の受信データを受け渡して前記第のスレッドの実行を再開させる第2の受信要求処理と、
    を含む請求項1記載の情報処理装置。
  3. 前記受信完了処理は、
    前記情報処理装置で実行されるスレッドのうち第のスレッドによって、前記他の情報処理装置で実行されるスレッドのうち第のスレッドを送信元とするデータの受信が要求された後、前記キューから完了通知を取り出し、当該完了通知に対応する、前記他の情報処理装置から受信した第1の受信データを特定し、前記第1の受信データに付加された、前記識別子のいずれかに対応する付加情報が、前記第のスレッドと前記第のスレッドとの組み合わせに対応する前記識別子と一致しない場合には、前記第のスレッドを待機状態に遷移させる受信要求処理と、
    前記情報処理装置で実行されるスレッドの実行順を制御するとともに、前記キューから完了通知を周期的に取り出すスケジューリング処理と、
    を含み、
    前記スケジューリング処理によって前記キューから取り出された完了通知に対応する、前記他の情報処理装置から受信した第2の受信データに付加された、前記識別子のいずれかに対応する付加情報が、前記第のスレッドと前記第のスレッドとの組み合わせに対応する前記識別子と一致する場合には、前記第のスレッドに前記第2の受信データを受け渡して前記第のスレッドの実行を再開させる、
    請求項1記載の情報処理装置。
  4. 前記識別子は、前記コネクションが確立された前記情報処理装置または前記他の情報処理装置を示す識別番号と、シーケンシャルに生成される番号とを組み合わせることで生成される情報を含む、
    請求項1乃至3のいずれか1項に記載の情報処理装置。
  5. 前記他の情報処理装置が複数接続されている場合、前記他の情報処理装置のそれぞれに対応する前記キューが使用され、
    記識別子は、前記情報処理装置で実行されるスレッドのうち第5のスレッドと、前記他の情報処理装置で実行されるスレッドのうち第6のスレッドとの間の前記コネクションが確立されたとき、前記第5のスレッドが実行される前記情報処理装置または前記第6のスレッドが実行される前記他の情報処理装置のいずれかを示す識別番号と、シーケンシャルに生成される番号とを組み合わせることで生成される情報を含む
    請求項1乃至3のいずれか1項に記載の情報処理装置。
  6. コンピュータが、
    他のコンピュータから、前記コンピュータで実行される複数のスレッドと、前記他のコンピュータで実行される複数のスレッドとの間でコネクションが確立されたスレッドの組み合わせごとに別々に規定される識別子のいずれかに対応する情報が付加されたデータを受信し、受信が完了したことを示す完了通知を、前記組み合わせごとに確立される前記コネクションにおける各々の完了通知の登録のために前記コンピュータで実行される複数のスレッドで共用されるキューに登録する受信処理と、
    前記キューに登録される1以上の完了通知の周期的な確認において、前記データに対応する完了通知が確認されて前記キューから前記データに対応する完了通知が取り出された場合に、前記識別子と前記組み合わせとの対応関係が登録された対応情報を参照し、前記コンピュータで実行されるスレッドのうち、前記データに付加された前記情報に基づき前記対応関係から特定される前記組み合わせに含まれるスレッドに、前記データを受け渡す受信完了処理と、
    を実行する情報処理方法。
  7. コンピュータに、
    他のコンピュータから、前記コンピュータで実行される複数のスレッドと、前記他のコンピュータで実行される複数のスレッドとの間でコネクションが確立されたスレッドの組み合わせごとに別々に規定される識別子のいずれかに対応する情報が付加されたデータを受信し、受信が完了したことを示す完了通知を、前記組み合わせごとに確立される前記コネクションにおける各々の完了通知の登録のために前記コンピュータで実行される複数のスレッドで共用されるキューに登録する受信処理と、
    前記キューに登録される1以上の完了通知の周期的な確認において、前記データに対応する完了通知が確認されて前記キューから前記データに対応する完了通知が取り出された場合に、前記識別子と前記組み合わせとの対応関係が登録された対応情報を参照し、前記コンピュータで実行されるスレッドのうち、前記データに付加された前記情報に基づき前記対応関係から特定される前記組み合わせに含まれるスレッドに、前記データを受け渡す受信完了処理と、
    を含む処理を実行させる情報処理プログラム。
JP2017082660A 2017-04-19 2017-04-19 情報処理装置、情報処理方法および情報処理プログラム Active JP6414269B1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2017082660A JP6414269B1 (ja) 2017-04-19 2017-04-19 情報処理装置、情報処理方法および情報処理プログラム
US15/954,111 US10318362B2 (en) 2017-04-19 2018-04-16 Information processing apparatus, information processing method, and non-transitory computer-readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017082660A JP6414269B1 (ja) 2017-04-19 2017-04-19 情報処理装置、情報処理方法および情報処理プログラム

Publications (2)

Publication Number Publication Date
JP6414269B1 true JP6414269B1 (ja) 2018-10-31
JP2018182628A JP2018182628A (ja) 2018-11-15

Family

ID=63853806

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017082660A Active JP6414269B1 (ja) 2017-04-19 2017-04-19 情報処理装置、情報処理方法および情報処理プログラム

Country Status (2)

Country Link
US (1) US10318362B2 (ja)
JP (1) JP6414269B1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020511808A (ja) * 2018-12-19 2020-04-16 アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited 共有秘密ベースのブロックチェーン記憶

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6414269B1 (ja) * 2017-04-19 2018-10-31 富士通株式会社 情報処理装置、情報処理方法および情報処理プログラム
WO2023058232A1 (ja) * 2021-10-08 2023-04-13 日本電信電話株式会社 通信システム、中間装置、通信方法、および、プログラム

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6721806B2 (en) 2002-09-05 2004-04-13 International Business Machines Corporation Remote direct memory access enabled network interface controller switchover and switchback support
JP5122587B2 (ja) * 2008-01-22 2013-01-16 株式会社エヌ・ティ・ティ ピー・シー コミュニケーションズ 接続制御方法、接続制御サーバ装置、接続制御クライアント装置、接続制御システム、及びプログラム
US8751737B2 (en) * 2009-06-26 2014-06-10 Alcatel Lucent Method and apparatus for using a shared ring buffer to provide thread synchronization in a multi-core processor system
US8543722B2 (en) * 2010-03-30 2013-09-24 International Business Machines Corporation Message passing with queues and channels
US8433833B2 (en) * 2011-03-30 2013-04-30 Intel Corporation Dynamic reassignment for I/O transfers using a completion queue
US9043796B2 (en) * 2011-04-07 2015-05-26 Microsoft Technology Licensing, Llc Asynchronous callback driven messaging request completion notification
JP2012226471A (ja) * 2011-04-18 2012-11-15 Hitachi Ltd 通信方法および通信サーバ
US9009702B2 (en) * 2011-11-30 2015-04-14 Red Hat Israel, Ltd. Application-driven shared device queue polling in a virtualized computing environment
JP5598493B2 (ja) * 2012-03-30 2014-10-01 富士通株式会社 情報処理装置、演算装置および情報転送方法
JP2015216450A (ja) 2014-05-08 2015-12-03 富士通株式会社 情報処理装置、情報処理システム及び中継プログラム
JP6414269B1 (ja) * 2017-04-19 2018-10-31 富士通株式会社 情報処理装置、情報処理方法および情報処理プログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020511808A (ja) * 2018-12-19 2020-04-16 アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited 共有秘密ベースのブロックチェーン記憶
JP7005639B2 (ja) 2018-12-19 2022-01-21 アドバンスド ニュー テクノロジーズ カンパニー リミテッド 共有秘密ベースのブロックチェーン記憶

Also Published As

Publication number Publication date
JP2018182628A (ja) 2018-11-15
US10318362B2 (en) 2019-06-11
US20180307548A1 (en) 2018-10-25

Similar Documents

Publication Publication Date Title
US8149854B2 (en) Multi-threaded transmit transport engine for storage devices
US8984222B2 (en) Methods and structure for task management in storage controllers of a clustered storage system
JP5352132B2 (ja) 計算機システム及びそのi/o構成変更方法
JP3762846B2 (ja) サーバのグループに関する作業負荷管理を行うデータ処理装置および方法
US7602774B1 (en) Quality of service for server applications
US20130097378A1 (en) Storage system and control method thereof as well as program
US20160077752A1 (en) Fibre Channel Storage Array Methods for Handling Cache-Consistency Among Controllers of an Array and Consistency Among Arrays of a Pool
US9712427B1 (en) Dynamic server-driven path management for a connection-oriented transport using the SCSI block device model
JP6414269B1 (ja) 情報処理装置、情報処理方法および情報処理プログラム
US7640549B2 (en) System and method for efficiently exchanging data among processes
JP2008015888A (ja) 負荷分散制御システム及び負荷分散制御方法
JPH08255122A (ja) クラスタ化コンピューティング・システムのディスク・アクセス・パスにおける障害から回復する方法および関連する装置
EP1131933A2 (en) Systems and methods for network and i/o device drivers
US20180260257A1 (en) Pld management method and pld management system
WO2020025049A1 (zh) 数据同步的方法、装置、数据库主机及存储介质
US10872036B1 (en) Methods for facilitating efficient storage operations using host-managed solid-state disks and devices thereof
US8275903B1 (en) Concurrent transmit processing
JP6390748B1 (ja) 情報処理装置、情報処理方法および情報処理プログラム
US7159010B2 (en) Network abstraction of input/output devices
US20200183875A1 (en) Usb transmission device and transmission method
US11442959B2 (en) System and method of time-based snapshot synchronization
US10067720B2 (en) Synchronous input/output virtualization
WO2009033971A1 (en) System and method for splitting data and data control information
US10530870B2 (en) Direct volume migration in a storage area network
WO2023116438A1 (zh) 一种数据访问方法、装置以及设备

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180816

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: 20180904

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180917

R150 Certificate of patent or registration of utility model

Ref document number: 6414269

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150