Download to read offline
![APUNet: Revitalizing GPU as Packet
Processing Accelerator (KAIST)
• パケット処理にGPUを使う研究(G-Opt[NSDI15])ではメモリコ
ピーの負荷がある。CPUと同じダイにあるIntegrated
GPU(AMD Accelerated Processing Unit)を使うことでアドレ
ス空間を共有し、効率的に処理するAPUNetの提案である。
APUNetはNetwork IDSにもAho-Corasickパターンマッチの高
速化に使えるとのことであった。
• GPUは普及するハードウェアであるが、メモリのコピーの課題
をAMDのAPUを使ってパケット処理と言うターゲットを絞って
活用するのは目の付け所がよい。](https://image.slidesharecdn.com/usenix-nsdi17-memorydisaggregation-170606224304/85/USENIX-NSDI17-Memory-Disaggregation-29-320.jpg)
Uploaded byKuniyasu Suzaki
USENIX NSDI17 Memory Disaggregation
第2回 システム系輪講会での報告 https://connpass.com/event/52323/
More Related Content
Similar to USENIX NSDI17 Memory Disaggregation
USENIX NSDI17 Memory Disaggregation
- 1. USENIX NDSI 2017報告 & EfficientMemory Disaggregation with Infiniswap (University of Michigan) 須崎有康 独立行政法人 産業技術総合研究所 第2回 システム系輪講会
- 2. NSDI2017概要 • 14th USENIXSymposium on Networked Systems Design and Implementation • https://www.usenix.org/conference/nsdi17 • MARCH 27–29, 2017, BOSTON, MA • 投稿数254本、採択46本、シングルセッション、キーノートなし。 • 主催者から発表された今年のNSDI論文で使われたキーワード • Security、Data Center、Distributed Systems、Big Data • Best Paper Award • mOS: A Reusable Network stack for Flow Monitoring Middleboxes (KAIST) • Community Award • Transparently Compress Hundreds of Petabytes of Image Files for a File- Storage Service (Stanford)
- 3. 個人的な感想 • ネットワークがメインでない発表が多くあり、なぜNSDIで発 表するのかと思われるものが幾つかあった。 • セキュリティは全13セッション中、２セッションあり、セキュ リティの関心の高い。 •韓国からは4本の論文(KAIST 3本、漢陽大学校1本)が採択され ており、存在感があった。特にKAISTはコンスタントに論文を 出している。 • SDN: Software Designed Networkに関する発表が多くあった。 • 他の会議では話題となっているzmapなどを使ったInternet全体 を対象にした調査がNSDIでは一つもなかったことが不思議
- 4. Efficient Memory Disaggregationwith Infiniswap (University of Michigan) • この論文に決めた理由
- 5. Infiniswap の概要 • Motivation •Memory Intensiveなアプリが多い。 • データセンターでのメモリ利用の偏り。 • RDMAを活用したDisaggregation Memory • Challenge • No application modification, Scalability, Fault-tolerance • Swapの二重化(RDMA or DISK) • Control Plane (各マシンのdeamon)とData Plane (RDMA)の分離。 • 4KB物理ページに対して(1GB) slabによる管理。 • decentralized slab placements and evictions. • power of two random choice.
- 6. Motivation 1 • MemoryIntensive applicationが多いが、
- 7. Motivation 1 • MemoryIntensive applicationが多いが、
- 8. Motivation 1 • アプリケーションによるMemoryOver Estimationによる性能劣化
- 9. Motivation 2 MemoryImbalance • 30%は割り当てて使われない。これを利用できないか？
- 10.
- 11.
- 12. System Overview • Disk(非同期書き込み)とRDMA(同期書き込み)の併用 •Fault Tolerant の確保 • Control Plane(Daemon)とData Plane(RDMA)の分離 • Daemonが領域管理を行う。
- 13.
- 14.
- 15.
- 16.
- 17.
- 18. power of tworandom choices • decentralized slab placements and evictionsの肝 • Michael Mitzenmacher, The Power of Two Choices in Randomized Load Balancing, Ph.D Thesis, 2001. • https://pdfs.semanticscholar.org/3885/812a092ff0aad3d45c0464660075e98d0231.pdf • Michael Mitzenmacher, Andrea Richa, Ramesh Sitaraman,The Power of Two Random Choices: A Survey of Techniques and Results, 1996. • http://www.ic.unicamp.br/~celio/peer2peer/math/mitzenmacher-power-of-two.pdf • Michael Mitzenmacher, The Power of Two Choices in Randomized Load Balancing, IEEE Trans. Parallel and Distributed Systems, 2001. • https://www.eecs.harvard.edu/~michaelm/postscripts/tpds2001.pdf
- 19. パラメータ • SlabSize=1GB • HeadRoom=8GB •Free Spaceの下限。これを超えるとSwap outする。 • HotSlab=20 • 一秒間のI/O Request数。不必要なslab Mappingを避ける。
- 20. 実装 • Linux 3.13.0のSwapを改良。3,500 LOC。 • Loadable Moduleとして実装。 • ndbX for Mellanox https://github.com/accelio/NBDXを活用。 • Stackdb (Stacking a block device over another block device https://github.com/OrenKishon/stackbd) を活用
- 21. 性能評価 • CloudLabのマシンを使う。 • InfiniSwap、通常のSwap(Disk)、nbdXon Mellanoxと比較。
- 22.
- 23. 性能評価 • Disk • nbdX •Infiniswap
- 24. Fault Tolerantのテスト • VoltDB(75%memory)、SLABマシン６台のうち、1台を落とし た場合の性能劣化。
- 25. Discussion • Application-aware Design •アプリがremote memoryを認識(頻繁に使うHot Tableと使わないCold Table)してプログラムしたほうが早い。 • 個人的なコメント：Linuxのmadvise()が使えないか？ • OS-Aware Design • SwapベースにしているためContext Switchのオーバーヘッドが馬鹿に ならない。
- 26. 個人的な疑問 • Remote-memoryを使うより、Memory IntensiveとCPUIntensive のアプリを混在させるスケジューラを使ったほうが全体的に効率的 では？ • 1GB Slabにある4KB PageがランダムにSwap Inされたら効率的？ • 複数アプリの4KB Pageが1GB Slabに割り当てられるのか？ • この場合、swap inがアプリ毎に変わるが効率的？
- 27. Conclusion • ソースコードは発表時にはComing Soonでしたが、公開されて います。 • https://github.com/Infiniswap/infiniswap • 質疑応答 • 質問：Infiniswap はLinuxのSWAPを改良しているが、Huge Pageは対応できるのか。たしか、LinuxのSWAPでは扱えない はずだが。 • 回答：現在のInfiniswapでもHuge Pageは扱えない。Future workだ。
- 28. The Design, Implementation,and Deployment of a System to Transparently Compress Hundreds of Petabytes of Image Files for a File-Storage Service (Dropbox, Stanford University) • Community Award Paper。JPEGファイルを保存するのにHuffman Codeから parallelized arithmetic codeでスキャンし直して保存するファイルシステムの Leptonの発表。圧縮率もCPU性能もよい。Lepton は2017年2月にDropBoxで 使われるようになっており、ソースコードも公開されている。 • PackJPG, MozJPG, JPEGreenなど類似に研究はあるが、JPEGの特徴を取り直 すためにHuffman Codeから別の圧縮方法でファイルシステムが対応するのは、 既存のフォーマットを残しつつシステム側で対応する新たな研究方向と思われ る。 • また、Leptonの実装ではセキュリティを確保するのにLinuxのSECCOMを使っ ている。また、C++のthreadで書かれているが、Deterministicを確保している など、セキュリチィや再現性にまで言及しており、研究の質の高さを示してい る。
- 29. APUNet: Revitalizing GPUas Packet Processing Accelerator (KAIST) • パケット処理にGPUを使う研究(G-Opt[NSDI15])ではメモリコ ピーの負荷がある。CPUと同じダイにあるIntegrated GPU(AMD Accelerated Processing Unit)を使うことでアドレ ス空間を共有し、効率的に処理するAPUNetの提案である。 APUNetはNetwork IDSにもAho-Corasickパターンマッチの高 速化に使えるとのことであった。 • GPUは普及するハードウェアであるが、メモリのコピーの課題 をAMDのAPUを使ってパケット処理と言うターゲットを絞って 活用するのは目の付け所がよい。
- 30. One Key toSign Them All Considered Vulnerable: Evaluation of DNSSEC in the Internet (Fraunhofer) • 現在使われている210万個のDNSSECの鍵の脆弱性調査の発表。 190万個がRSA keyであり、このうち66％が1024bit以下。また、 共通のモジュラスや素数も見つかっている。 • モジュラスが共通だとCommon Modulus Attackが可能となる。 • この発表がインターネット全体を調査した唯一のものであった。 他の一流会議では2,3本あるのに対して、ネットワークが主眼な 会議にしては少ない。
- 31. Enhancing Security andPrivacy of Tor's Ecosystem by Using Trusted Execution Environments (KAIST) • Torではリレーノードが改ざんされてプライバシーが守れなく なる脆弱性がある。Intel SGXを使い、TEE: Trusted Execution Environmentによる安全なリレーノード検出し、それらのみを 使うSGX-Torの提案。Remote Attestationで検証し、承認され たRelayのみを使う。SGX-Tor の実装ではEnclave中にSSL Library(OpenSSL), zlib, libevnetが含まれる。 • 性能劣化は11.9％。 • SGX-Torのソースコード • https://github.com/KAIST-INA/SGX-Tor
- 32. Opaque: An Obliviousand Encrypted Distributed Analytics Platform, (UCB) • SQLの処理に Hardware enclave(Intel SGX, AMD memory encryption)を使ってもAccess pattern leakageがある。アクセ スパターンを隠すoblivious relational operatorsを加えたSpark SQLのOpaqueの提案である。 • OpaqueのHP。ソースコードあり • https://github.com/ucbrise/opaque
- 33. Bringing IoT toSports Analytics, (University of Illinois at Urbana–Champaign) • 現在のスポーツ解説はハイスピードカメラを使って軌跡を追う ことができるが、機材が高い。この問題を解決するために、ク リケットのボールの中に加速度計、ジャイロ、磁力計、WiFiを 入れて軌跡を追うiballの発表。位置検出は複数のWiFiインフラ を使う。 • 位置検出にGPSではなく、WiFiによるものが興味深い。また、 フリーフォールでは加速度計は０になるので活用できなくなる 問題あり。
- 34. Clipper: A Low-LatencyOnline Prediction Serving System (USB) • 現在のMachine LearningはGoogle TensorFlowのように専用の ハードウェアを使って性能向上を図っているが、このような専 用化は変更が難しい。汎用にする技術ためにLayered Architectureを採用したClipperの提案。Spark, Tensor Flow, Caffeのエンジンが抽象化されるModel Abstraction Layer とそ れを活用するアプリを抽象化したModel selection layerで構成 される。Model Abstraction Layerは複数のエンジンを配下に置 くことができる。 • Clipperのソースは一か月後に公開されるそうだ。現在公開済み。 • https://github.com/ucbrise/clipper
- 35. Gaia: Geo-Distributed MachineLearning Approaching LAN Speeds (CMU, ETH) • 世界中に散らばったデータセンタをMachine Learningで使える ようにするGeo-distributed ML systemのGaiaの提案。 Parameter serverで各データセンタを調整する。レイテンシを 隠すためにデータ転送、同期などの工夫し、LANに近い性能を 達成。