ASPLOS 2012 出張報告

Transcript

1. ASPLOS 2012 出張報告 東京大学情報基盤センター 品川高廣
2. ASPLOS 2012概要（１）  The 17th International Conference on Architectural Support for Programming Languages and Operating Systems  第１回は1982年，2008年までは隔年，2009年から毎年開催 2012/4/25 2
3. ASPLOS 2012概要（２）  The Royal Society （王立協会）, London, UKで開催 2012/4/25 3
4. ASPLOS 2012概要（３）  採択率は21.5% (37/172)  ラウンド１: 172 本⇒101本  査読者3名以上，「平均点＜3.5点＆最高点＜5点」の71本を排除  ラウンド２: 101本⇒74本  PCメンバー2名による追加査読（平均的PCは14本査読）  反証期間（rebuttal period）: 著者が反論  ラウンド３: 74本⇒37本  PCメンバー全員で一日かけて議論  9本がshepherdされた  分野  Operating systems (34%)  Compilers and programming languages (28%)  Core topics in computer architecture (37%)  参加者  大平 怜さん（日本IBM）が発表  日本人は参加者数が第２位 2012/4/25 4
5. ASPLOS 2012概要（４） 会場（オープニング時の様子） 昼食 2012/4/25 5
6. 紹介論文  Data Center / Cloud Computing  (Best Paper) Clearing the Clouds: A Study of Emerging Workloads on Modern Hardware  OS / Fault Tolerance  Understanding Modern Device Drivers  Cosmic Rays Don't Strike Twice: Understanding the Nature of DRAM Errors and the Implications for System Design  Virtualization  ELI: Bare-metal Performance for I/O Virtualization  Architectural Support for Hypervisor-secure Virtualization 2012/4/25 6
7. (Best Paper) Clearing the Clouds: A Study of Emerging Workloads on Modern Hardware.  背景: クラウド・データセンターでの電力効率問題  Compute density / power consumption の向上が必要  問題: scale-out 負荷ではプロセッサの電力効率が低い  Scale-up 負荷を想定した設計  アウトオブオーダ実行，深いキャッシュ階層  内容：scale-out 負荷でのアーキテクチャ的問題を分析  Scale-out 性能を測定する「CloudSuite」ベンチマークを導入  Data Serving, MapReduce, Media Streaming, SAT Solver, Web Frontend, Web Search  従来の scale-up 負荷と比較  PARSEC, SPECint, SPECweb09, TPC-C, TPC-E, Web Backend  現状のプロセッサの問題点を4点指摘，今後もその傾向は継続  命令キャッシュのサイズ，命令・メモリ並列性，データワーキングセット，チップ内・ チップ間通信帯域 2012/4/25 7
8. (Best Paper) Clearing the Clouds: A Study of Emerging Workloads on Modern Hardware.  Scale-out workload における4つの問題点  【フロントエンド】 命令キャッシュのミス率増加  L2 より大きいが L3 よりは小さい⇒命令フェッチ遅延→コアストール  【コア】 命令レベル・メモリレベル並列性が低い  ILP は 0.6～1.1, MLP は 1.4～2.3 ⇒多数のCPU資源が無題になる  分岐予測，ALU，forwarding paths, レジスタバンク，スケジューラ，ROB, LSQ, …  【データアクセス】 ワーキングセット（<2MB） ＜ L3 キャッシュ  L3 がチップの広範囲を占めるわりに性能は向上しない  プリフェッチも効かないか逆効果（あちこちアクセスする）  【帯域幅】 広帯域の必要性が低い  共有データは少ない  メモリ帯域利用率は 15% 程度まで→帯域の無駄 2012/4/25 8
9. Understanding Modern Device Drivers 2012/4/25 9  背景: デバイスドライバはOSのコードの多くを占めている  Linuxの70%，バグの温床，研究も多数  Shadow driver, RevNIC, Nooks, Palladium, XFI, Devil, Micro-drivers, etc.  問題: 多くの研究は一部のクラスのデバイスのみ扱う  NIC, sound card, storage deviceなど  他のデバイスの性質は知られていない  内容: デバイスドライバの様々な性質を明らかにする  Linuxの全てのデバイスドライバを調査  “DrMiner”でdata-flow analysis, ”DrComp”で類似コード抽出  デバイスの挙動を推測  ドライバは何をしているか？，ドライバの相互作用，ドライバの冗長性
10. Understanding Modern Device Drivers 2012/4/25 10  ドライバは何をしているか？  研究時のドライバの挙動に対する前提を検証  request handling and interrupts (only 23.3%), initialization and cleanup (36%), error handling (5%), configuration (15%), power management (7.4%), ioctl handling (6.2%)  15%のドライバは計算処理をしている（sound, NIC, wireless, CD-ROM, ..）  複数デバイスサポート（3,217個のバス・デバイスドライバで14,000デバイス）  ドライバの相互作用  デバイス内プロセッサの活用，汎用性向上，隔離用インターフェイス  {Kernel library, Memory management, Synchronization}, Device library, Kernel services  多くのドライバはカーネルサービスとの相互作用少⇒ユーザレベル・VM等での隔離が容易  デバイスもカーネルも直接は呼び出さないドライバ⇒”miniport”ドライバとして単純化可能  ドライバの冗長性  ライブラリやサブシステムによる抽象化の機会  8%のコードに類似性がある
11. Cosmic Rays Don't Strike Twice: Understanding the Nature of DRAM Errors and the Implications for System Design 2012/4/25 11  背景: DRAMエラーはデータセンターでの主要な障害要因  Soft-error には ECC による SEC-DED が有効  α線や宇宙線などによる一時的エラー  Hard-error には page retirement が有効  Solaris は壊れたページを特定して使用不可にする  問題: soft-errorの頻度＞hard-errorの頻度は本当か？  発生頻度は桁が違うと言われている  多くの研究はsoft-errorを対象としている  実際にそれを裏付ける大規模な field work は存在しない  内容: 実システムにおける大規模なDRAMエラーの分析  IBM Blue Gene/L, Blue Gene/P, SciNet のスパコン・クラスタ, Googleデータセンタからランダムに選択した20,000台のマシン  総計300テラバイト・年のメモリを調査
12. Cosmic Rays Don't Strike Twice: Understanding the Nature of DRAM Errors and the Implications for System Design 2012/4/25 12  方法: アプリケーションで繰り返しメモリアクセス  同一カ所の繰り返しエラーをhardと識別  同じ場所に２度cosmic rayが来る可能性は極めて低い  結果:  エラーが発生したメモリバンクの3分の1以上がhard errorの兆候  ２週間以内に同じ物理アドレスでエラーが発生  あるシステムでは95%以上がhard error  領域によってエラー発生率に偏りがある（特定のrow/column）  ＯＳが酷使する領域はエラーが起きやすい傾向にある  より複雑なエラーには前兆がある場合が多い  Multi-bit errorsやchipkillの前に特定箇所に繰り返しエラー発生  ECCによるSEC-DEDでは解決できないエラーも多発  20%～45%のreduandant bit-steering, 15%のchipkill
13. ELI: Bare-metal Performance for I/O Virtualization 2012/4/25 13  背景：仮想化環境におけるI/O性能  デバイスのゲストへの直接割当が活用（GPU, NIC, Diskなど）  問題：Bare-Metalの60～65%の性能しか出ない  割り込み前後での ”VM exit” のコストが大きい（～150K回/s）  提案：ELI (Exit-Less Interrupts): 割り込みを直接ゲストに  IDT（割り込みテーブル）をシャドウ化  VMM (Hypervisor)がIDTの中身を制御  直接割当デバイス以外のハンドラを “non-present” に設定  通常デバイスへの割り込み発生時はVMMに制御が移る  直接割当デバイスへの割り込みは直接ゲストに送られる  ゲストから EOI の発行などを可能にする  最新の x2APICを使用（レジスタ単位で exit の有無を設定可能）  xAPICまではMMIOなのでページ単位でしかexitの有無を設定不可能
14. Architectural Support for Hypervisor-secure Virtualization 2012/4/25 14  背景: ハイパーバイザの普及  Amazon EC2等のIaaS型クラウドで活用  問題: ハイパーバイザからVMを守れるか？  ハイパーバイザが乗っ取られた時のVMの機密性・完全性維持  普通はハイパーバイザが全権限を持っている  提案: hypervisor-secure virtualization (HyperWall)  CPUを拡張して保護機構を導入する  CIP (Confidentiality and Integrity Protection) table  ハイパーバイザやDMAからのページ単位のメモリ保護  VM終了時のメモリゼロ初期化  CPU内電子署名による保護状態のチェック  VMの起動や停止など管理タスクはハイパーバイザが実行