Recommended
More Related Content
What's hot
What's hot (20)
Similar to Takahashi Bachelor thesis
Similar to Takahashi Bachelor thesis (20)
More from pflab
More from pflab (19)
Takahashi Bachelor thesis
- 1. Cache-Aware Splitkernel キャッシュを考慮したスプリットカーネル 情報科学科4年 加藤研究室 05-171018 高橋 昂良
- 2. 背景 従来のデータセンタの問題 アプリケーションに適した形でのハードウェアの構成が困難 一度ハードウェアを構成すると変更が困難 既存のシステムによる新規に導入するハードウェアの性能制限 Facebook. Wedge 100: More open and versa- tile than ever. https://code.fb.com/networking-traffic/ wedge-100-more-open-and-versatile-than-ever/ ハードウェアの相性の問題など
- 3. ハードウェア資源をコンポーネント化した分散OS(スプリットカーネル) コンポーネント • pComponent (プロセッサ) • mComponent (メインメモリ) • sComponent (ストレージ) 利点 • ハードウェアの構成の柔軟性 • 故障部位のアイソレーション • ハードウェアの新規導入が容易 LegoOS Yizhou et al. , “LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation”, OSDI, 2018. ノード (計算機) OS ノード (計算機) OS ノード (計算機) OS OS 従来の分散OS LegoOS sComponent pComponent mComponent ネットワークスイッチ メモリ用 コンポーネント (計算機) ストレージ用 コンポーネント (計算機) プロセッサ用 コンポーネント (計算機) ネットワークスイッチ
- 12. 提案 : ExCacheへのプリフェッチ機構の導入 バックグラウンドで連続するラインをプリフェッチ テキスト領域はプリフェッチの対象から除外 テキスト領域は連続的局所性を持たずプリフェッチの効果が薄いため 2-way ExCacheにおいて2ライン分プリフェッチする様子 2-way ExCache メモリ セット セット セット バックグラウンド でのプリフェッチ (本研究での提案) 4KB 4KB 4KB 4KB 4KB 4KB プロセッサ pComponent (プロセッサ用の計算機) mComponent (メモリ用の計算機) InfiniBand 1ラインのフェッチ (既存手法)
- 19. 実装 ExCacheの動作を模倣するエミュレータを実装 LegoOSを十分に模倣可能なパラメータを設定 InfiniBandによる通信遅延の考慮等 Linux上でC言語による実装 実験プログラムの実行に必要な疑似命令セットを実装 LegoOS ExCacheのフェッチ 30 us 1命令の処理時間(1ステップ) 0.4167ns 約72000倍 フェッチ時に エミュレータ上で 72000ステップ分の 遅延を挿入 時間スケールを合わせるため Yizhou et al. , “LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation”, OSDI, 2018.
- 20. 評価 連続的なメモリアクセスを行うマイクロベンチマーク 512 * 512ピクセルの画像のRGBデータに対するアクセス TensorFlowを想定 擬似命令セット上のアセンブリで実装 指標 ExCacheのサイズ（512MBと1MB） テキスト領域のプリフェッチの有無 環境 CPU: Intel Core i7-6700K 4.00GHz (4 cores / 8 threads) メモリ: 16GB (DDR4 SDRAM) OS: Ubuntu 16.04 LTS（Linuxカーネル: 4.4.0）
Editor's Notes
- 背景について説明します。 本研究では、データセンターに着目しました。 従来のデータセンターは、相性などの関係からハードウェア周りでの問題を抱えていると言われています。 例えば、データセンターで走る複数のアプリケーションに最適化した形でハードウェアを構成するのが難しかったり、 一度ハードウェアを構成してサーバーを構築してしまうと後からのサーバーの構成変更が難しかったりします。 また、出来上がったサーバーのシステムに新しくハードウェアを導入しようと思っても、既存の構成が邪魔をして、新しいハードウェアの性能を活かしきれないこともあります。 実際にFacebook社では、ハードウェア交換の難しさが問題として挙げられています。
- このようなデータセンターの問題を解決する既存の研究の一つとしてLegoOSというものがあります。 LegoOSはプロセッサなどのハードウェアをモジュール化することに焦点を当てた分散オペレーティングシステムです。 このOSでは、スプリットカーネルが使われており、ハードウェアを以下のようにモジュール化しています。 従来は、ノード内のハードウェアしか一つのまとまりとしてOSが扱うことはできませんでしたが、 LegoOSでは、別々のノードのハードウェアをOSが一つのまとまりとして扱うことができるようになりました。 これによって、次に述べるような利点が生まれました。 ハードウェアの構成に柔軟性が生まれたり、 故障部位のアイソレーションができたり、 新しいハードウェアを導入しやすくなったりしています。
- しかしながら、ハードウェアが分散しているため、各ハードウェアは通信してデータをやりとりする必要があります。 したがって、通信のコストが増大してしまい、従来のOSと比べると性能が劣化してしまいます。 例えば、プロセッサーとメモリが離れてしまっているので、プロセッサーが次に実行する命令を読み込む際に、 メモリを持つマシンに対してデータを要求する必要があります。 要求されたmComponentは要求されたデータを送信し、そこで初めてプロセッサが命令を実行することができます。 こうした通信のコストの増大が一つの問題として挙げられます。
- しかしながら、ハードウェアが分散しているため、各ハードウェアは通信してデータをやりとりする必要があります。 したがって、通信のコストが増大してしまい、従来のOSと比べると性能が劣化してしまいます。 例えば、プロセッサーとメモリが離れてしまっているので、プロセッサーが次に実行する命令を読み込む際に、 メモリを持つマシンに対してデータを要求する必要があります。 要求されたmComponentは要求されたデータを送信し、そこで初めてプロセッサが命令を実行することができます。 こうした通信のコストの増大が一つの問題として挙げられます。
- しかしながら、ハードウェアが分散しているため、各ハードウェアは通信してデータをやりとりする必要があります。 したがって、通信のコストが増大してしまい、従来のOSと比べると性能が劣化してしまいます。 例えば、プロセッサーとメモリが離れてしまっているので、プロセッサーが次に実行する命令を読み込む際に、 メモリを持つマシンに対してデータを要求する必要があります。 要求されたmComponentは要求されたデータを送信し、そこで初めてプロセッサが命令を実行することができます。 こうした通信のコストの増大が一つの問題として挙げられます。
- しかしながら、ハードウェアが分散しているため、各ハードウェアは通信してデータをやりとりする必要があります。 したがって、通信のコストが増大してしまい、従来のOSと比べると性能が劣化してしまいます。 例えば、プロセッサーとメモリが離れてしまっているので、プロセッサーが次に実行する命令を読み込む際に、 メモリを持つマシンに対してデータを要求する必要があります。 要求されたmComponentは要求されたデータを送信し、そこで初めてプロセッサが命令を実行することができます。 こうした通信のコストの増大が一つの問題として挙げられます。
- Linuxでのページングなど、一般に離れたところからは、ある程度まとめてデータを取ってくる方が効率的であるという考え方に基づくと、 これは非効率であると考えられます。 通信コストの問題を解決するためにpComponent内にExCacheという容量の大きいキャッシュがLegoOSでは設けられています。 各コンポーネントはInfiniBandによって接続されていますが、それでも同一マシン内のメモリに対するアクセスに比べれば速度は劣ります。 したがって、同一マシン内で扱える一時的なメモリとしてExCacheが存在します。 pComponentはデータを読み込む際にこのExCacheを参照することで、ExCacheにデータがある場合は、mComponentへの通信をする必要はありません。 また、ExCache1ラインの大きさは4KBとなっています。 LegoOSではExCacheの連想度は一般に64とされており、サイズは512MBや1GBが使われています。
- Linuxでのページングなど、一般に離れたところからは、ある程度まとめてデータを取ってくる方が効率的であるという考え方に基づくと、 これは非効率であると考えられます。 通信コストの問題を解決するためにpComponent内にExCacheという容量の大きいキャッシュがLegoOSでは設けられています。 各コンポーネントはInfiniBandによって接続されていますが、それでも同一マシン内のメモリに対するアクセスに比べれば速度は劣ります。 したがって、同一マシン内で扱える一時的なメモリとしてExCacheが存在します。 pComponentはデータを読み込む際にこのExCacheを参照することで、ExCacheにデータがある場合は、mComponentへの通信をする必要はありません。 また、ExCache1ラインの大きさは4KBとなっています。 LegoOSではExCacheの連想度は一般に64とされており、サイズは512MBや1GBが使われています。
- Linuxでのページングなど、一般に離れたところからは、ある程度まとめてデータを取ってくる方が効率的であるという考え方に基づくと、 これは非効率であると考えられます。 通信コストの問題を解決するためにpComponent内にExCacheという容量の大きいキャッシュがLegoOSでは設けられています。 各コンポーネントはInfiniBandによって接続されていますが、それでも同一マシン内のメモリに対するアクセスに比べれば速度は劣ります。 したがって、同一マシン内で扱える一時的なメモリとしてExCacheが存在します。 pComponentはデータを読み込む際にこのExCacheを参照することで、ExCacheにデータがある場合は、mComponentへの通信をする必要はありません。 また、ExCache1ラインの大きさは4KBとなっています。 LegoOSではExCacheの連想度は一般に64とされており、サイズは512MBや1GBが使われています。
- Linuxでのページングなど、一般に離れたところからは、ある程度まとめてデータを取ってくる方が効率的であるという考え方に基づくと、 これは非効率であると考えられます。 通信コストの問題を解決するためにpComponent内にExCacheという容量の大きいキャッシュがLegoOSでは設けられています。 各コンポーネントはInfiniBandによって接続されていますが、それでも同一マシン内のメモリに対するアクセスに比べれば速度は劣ります。 したがって、同一マシン内で扱える一時的なメモリとしてExCacheが存在します。 pComponentはデータを読み込む際にこのExCacheを参照することで、ExCacheにデータがある場合は、mComponentへの通信をする必要はありません。 また、ExCache1ラインの大きさは4KBとなっています。 LegoOSではExCacheの連想度は一般に64とされており、サイズは512MBや1GBが使われています。
- 本研究では、ExCacheへのプリフェッチ機構の導入を提案します。 現状のExCacheには、プリフェッチ機構が存在しません。 従来のOSでは、ページングなどでもプリフェッチ機構が存在し、それによってパフォーマンス向上がされているので、 ExCacheもプリフェッチ機構の導入によるパフォーマンス向上の余地があると考えられます。 本研究では、アドレス的に連続するラインをバックグラウンドでプリフェッチする手法について検証をしました。 また、テキスト領域に対するプリフェッチを回避することでパフォーマンスを維持しようと考えました。 これは、意味のないプリフェッチを減らすために行いました。
- プリフェッチの動作について説明します。
- プリフェッチの動作について説明します。
- プリフェッチの動作について説明します。
- プリフェッチの動作について説明します。
- プリフェッチの動作について説明します。
- プリフェッチの動作について説明します。
- 本来であれば、LegoOSであったり、Linux上で評価する方が確実なのですが、実装が間に合わなかったため、 ExCacheの動作を模倣するエミュレータを実装いたしました。 エミュレーションの実装についての説明をします。 実装はC言語を用いて行いました。 実装を簡易的なものにするために整数型の配列を用いて、メモリとExCacheを表現しました。 また、データアクセスに対するプリフェッチの評価をとるために、疑似的な命令セットを用意しました。 したがって、エミュレータは、メモリにセットされている命令を読んで簡単な実験用のプログラムを実行することができます。 プリフェッチの実装としては、本来フェッチされるExCacheのキャッシュラインに加えて、連続しているアドレスの部分のラインをバックグラウンドでプリフェッチするアルゴリズムを実装しました。 図は、仮に2wayのExCacheにおいて2ライン分プリフェッチする場合のイメージです。 Linuxでやった理由などをワンクッション挟む形でスライドを一つ作る(できれば) Linux上でのアプリケーションによるエミュレーション C言語による実装 メモリとExCacheの簡易な表現 疑似的な命令セットによる簡易的な実験用プログラムの実行が可能 プリフェッチ バックグラウンドスレッドを用いて、連続するアドレスのラインをフェッチしてくるような実装 InfiniBandの高速な通信はLinux上で行われる通信よりも高速で再現が困難 LinuxはLegoOSよりも規模が大きく、パラメータの制御が困難
- 評価についての説明をします。 プリフェッチによって高速化されるメモリのパターンは連続的なアクセスであると考えられます。 データセンターのアプリケーションでは、画像を用いた機械学習などが挙げられ、このようなアプリケーションでは連続的なデータへのアクセスが存在します。 したがって、本研究の評価では512*512の画像データを格納するに足りる領域に対して連続的にアクセスするような簡易的なプログラムを作成し用いました。 また、評価はExCacheに余裕がある場合とない場合に分けて行いました。 連続的なメモリアクセスをするマイクロベンチマーク 512 * 512の画像に対するアクセス TensorFlowで画像を用いたネットワークのトレーニングを想定 擬似命令セット上のアセンブリで実装 指標 ExCacheのサイズ（512MBと1MB） テキスト領域のプリフェッチの有無 環境 CPU: Intel Core i7-6700K 4.00GHz (4 cores / 8 threads) メモリ: 16GB (DDR4 SDRAM) OS: Ubuntu 16.04 LTS Linuxカーネル: 4.4.0 GCC: version 7.30
- 512MBの結果であること プログラムサイズよりもキャッシュサイズが大きいこと 余裕がある場合にはテキスト領域のプリフェッチの有無にかかわらずパフォーマンスが向上したこと 具体的にはどちらもエミュレータ上での実行時間が約9%短縮されていること
- 1MBの結果であること プログラムサイズは3MBであること プログラムサイズよりもキャッシュサイズが小さいこと 余裕がない場合には、テキスト領域のプリフェッチがあるときはパフォーマンスの低下が見られたこと しかし、テキスト領域のプリフェッチをなくすとパフォーマンスが低下することはなく、最大で約12%の実行時間の短縮が見られたこと テキスト領域のプリフェッチがある場合も、実行時間の短縮という意味では性能が低下する直前では最大で約10%の短縮が見られたこと
- 具体的には、LegoOS上では、RDMAがExCacheのフェッチに用いられており RDMAはハードウェアによって制御されるもので、OSはその状況を知ることはできないこと。 そのため、プリフェッチなどでRDMAのリクエストを発行すると、可能性の一つとして大量のリクエストでネットワークの帯域を圧迫することも考えられること。 そうしたプリフェッチを導入することによる影響をよりクリアにするために、LegoOS上での検証が必要だと考えていること