分散共有メモリ型組込みシステムにおける遅延性能確保とコア割付け自由化に関する一手法

全文

(1)情報処理学会第 74 回全国大会. 3A-1. 分散共有メモリ型組込みシステムにおける遅延性能確保とコア割付け自由化に関する一手法撰. 暁久†. 大塚. 潤†. 桐生. 隆介‡ 富士通（株）‡. 富士通九州ネットワークテクノロジーズ（株）†. 1. 背景と目的近年，組込み機器のデータプレーンの処理をハードウェアではなく，マルチコアプロセッサを使いソフトウェアで並列処理する事例が増えている．このような並列処理では AMP を用いるためタスクをコアへ静的に割付ける Affinity 設定が必要で，組込み機器においては CPU のコストを極力削減したいためその最適化には試行錯誤を伴う．そのためコア割付け変更の容易性が開発効率化上，重要となる．それらマルチコアプロセッサを複数個高速 IO で結合したクラスタ構成においては，特定プロセスが他プロセスとデータを受け渡す際に，チップ内通信かチップ間通信かで宛先や通信手段を変える必要がある．ところがコア割付け変更の容易性のためにこの違いを socket や TIPC[1] など既存の IPC ライブラリで隠蔽したコードを書いた場合, 通信遅延が数 10us～100us 超と大きくなりすぎる課題があった．そこで本稿では，クラスタ用フレームワークを開発し，数 us レベルの低遅延性能とコア割付け自由化を両立させる開発手法について述べる．. 2. 開発したフレームワーク一般に並列処理で遅延性能を高めるためには，データを処理するコアと，コア間でデータ転送する Direct Memory Access（以降 DMA と略）が，お互い待合せる事なく並列動作することが重要となる．そのために処理面と転送面とを交互に使用するダブルバッファを転送区間毎に個別に持ち，コア処理中に DMA が裏で次の処理データをオーバラップ転送する事により各送受信コアが独立に並列動作できる事を基本とした．転送区間毎に用意するバッファにデータが直接送られるため，受信タスクはドライバからのコピーやキューイングが介在することなく処理を始められる．これをチップ内，チップ間で同じ転送. メニューを提供できる様に隠蔽化するために，両 DMA で共通的に提供されている転送機能を抽出して論理レベルで指定可能なメニューとし，宛先コアやアドレスなどハード依存するコードをコード自動生成により埋め込むことにした．尚，チップ間 DMA には Serial Rapid IO（以降 sRIO と略）の DirectIO モードを用いる事でクラスタ内の全 CPU の任意のメモリ空間へ互いに DMA 転送できる構成とした．. コンパイルタイム. コード自動生成性能：経路毎最適に個別生成したAPI で直接DMA. 機能C. ランタイム. 機能A Send_B 自動生成API 自動生成. 機能B Buf_C. Send_C. CPU1. 機能B Buf_A Buf_B. 論理層. sRIOスイッチフレームワーク層. CPU0. 柔軟性：機能のコア割付けを簡単に変更可能. 物理層. Buf_B’. CPU2. 図 1 開発した開発したフレームワークしたフレームワーク概要フレームワーク概要. 開発したフレームワークの概要図を図 1に示す．コンパイル時にアプリ開発者が記入した論理定義と物理定義を基に転送経路毎の IPC ライブラリ（以降 API と呼ぶ）や，受信バッファ領域定義などのソースファイルを自動生成するツールを開発した．アプリ開発者が転送経路毎に生成された API を Call するように記述するだけで， A method to reduce tradeoffs between performance goal and 実行時には API 内で論理→物理変換が行われ， ease of affinity change on clustered embedded systems. 論理定義に指定した宛先の物理アドレスへデー † Akihisa Erami, Fujitsu Kyushu Network Technologies Ltd. タが転送される．例えば図 1で，タスク B の割 † Jun Ohtsuka, Fujitsu Kyushu Network Technologies Ltd. ‡ Ryusuke Kiryu, Fujitsu Ltd. 付けを CPU#0 から CPU#2 へ物理定義上変更した. 1-25. Copyright 2012 Information Processing Society of Japan. All Rights Reserved..

(2) 情報処理学会第 74 回全国大会. 場合，再度自動生成すると受信バッファは CPU#2 のメモリ上 B’の位置へ移動し，CPU#0 のタスク A が call する API の内部はそれまでのチップ内通信から，宛先 CPU#2 の B’へのチップ間通信へ変更される．ここでタスク B のコア割付け変更に際して，タスク A,B 共にコードを修正する必要は無くなった．. sRIO ドライバ単体での遅延時間に比べ，フレームワークを適用した遅延時間はいずれのデータ長においても一定の数 us のオーバヘッドしか観測されなかった．TIPC の遅延時間と比べると約 1/4～1/5 の値であった．. 5. 考察. 遅延性能の測定結果は，ほぼ期待通りの低遅延を実現できた．測定は全て 1 回のデータ転送によるものであり，CPU#2 で受信データを返送す遅延性能測定の構成について述べる．チップ間の測定では２つの CPU#1/#2 間を sRIO で接続し，る際コアによるコピーが発生しない為，全データ長で同様のオーバヘッドになったのは予想通 CPU#1 から送信したデータを CPU#2 で折り返しそりである．sRIO はハードによる送達確認機構をのまま CPU#1 へ返送する構成において，CPU#1 で持つ等 GbE に比べ元々遅延性能に優れる[2]為，データ送信前から返送データ受信後までの所要 TIPC より結果が良いのは想定済である．初回のサイクル数を測定し時間に換算し 1/2 にした．チップ内の測定は同様の事をコア間で実施した．測定結果が悪い結果になっているのは API がキャッシュミスした為と思われる．自動生成によ評価環境にはチップ内・チップ間の DMA を複数り経路毎個別の API を生成している為， 1 箇所チャネル具備するマルチコア CPU を OS 無しで使のドライバコードで全経路分を処理する場合に用した．尚，参考の為に TIPC について，同程度比べ，i キャッシュはミスする確率が高い．生成の処理能力の CPU に Linux を載せ GbE で 2 台対するコードのバイナリを極力 1 キャッシュライ向させて同様の測定を実施した．尚，チップ間ンに収める工夫を行ってはいるが，使用におい sRIO は実運用より遅い 1.25GHz×1 レーンで使用ては無闇に 1 コアが扱う転送経路数を増やしすし，比較対象の TIPC で使用した GbE と物理的にぎない様，アプリ設計に注意が必要であろう．同条件にした．一方，コア割付け変更の容易性については，目的は達成されたが，弊害も出た．コア割付け 4. 性能評価結果変更やバッファサイズ・数変更により，割付変遅延性能測定結果を図 2，及び図 3 に示す．更当事者でないコアについても受信バッファの 18000 16000 アドレスが変わり，その都度全 CPU で再ビルド 14000 が必要となった．これについては自動生成ツー 12000 ルのバッファ割付アルゴリズムを修正すること 10000 ﾌﾚｰﾑﾜｰｸ（チップ間）である程度軽減することができたが，フルメッﾌﾚｰﾑﾜｰｸ（チップ内） 8000 シュのトポロジを許容する仕組みである以上， 6000 4000 完全に避ける事はできない問題である．遅延時間[ns]. 3. 性能評価方法. 2000 0 1. 2. 3. 4. 5 6 測定回. 7. 8. 9. 6. 結論. 10. 図 2 送受信合計遅延時間の送受信合計遅延時間の測定結果[1KB 測定結果[1KB 転送] 転送] 700 600. 本稿のフレームワークを開発したことにより，遅延性能目標とタスクのコア割付け変更の容易化を両立させる事ができ，開発効率化に効果があった．. 転送遅延[us]. 500 400. 7. 参考文献. TIPC ﾌﾚｰﾑﾜｰｸ sRIOのみ. 300. [1] “TIPC Home Page”, http://tipc.sourceforge.net/ [2] “Serial RapidIO vs 10Gigabit Ether” http://www.idt.com/content/facn_idt_feb2011 _Print.pdf. 200 100 0 0. 5000. 10000. 15000. 20000. 転送データサイズ[byte]. 図 3 TIPC とのチップとのチップ間転送遅延比較チップ間転送遅延比較. 1-26. Copyright 2012 Information Processing Society of Japan. All Rights Reserved..

(3)