1. ASPLOS 2012
出張報告
東京大学情報基盤センター
品川高廣

2. ASPLOS 2012概要（１）
 The 17th International Conference on Architectural Support for
Programming Languages and Operating Systems
 第１回は1982年，2008年までは隔年，2009年から毎年開催
2 2012/4/25

3. ASPLOS 2012概要（２）
 The Royal Society （王立協会）, London, UKで開催
3 2012/4/25

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）が発表
 日本人は参加者数が第２位
4 2012/4/25

5. ASPLOS 2012概要（４）
昼食
会場（オープニング時の様子）
5 2012/4/25

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
6 2012/4/25

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点指摘，今後もその傾向は継続
 命令キャッシュのサイズ，命令・メモリ並列性，データワーキングセット，チップ内・
チップ間通信帯域
7 2012/4/25

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% 程度まで→帯域の無駄
8 2012/4/25

9. Understanding Modern Device Drivers
 背景: デバイスドライバはOSのコードの多くを占めている
 Linuxの70%，バグの温床，研究も多数
 Shadow driver, RevNIC, Nooks, Palladium, XFI, Devil, Micro-drivers, etc.
 問題: 多くの研究は一部のクラスのデバイスのみ扱う
 NIC, sound card, storage deviceなど
 他のデバイスの性質は知られていない
 内容: デバイスドライバの様々な性質を明らかにする
 Linuxの全てのデバイスドライバを調査
 “DrMiner”でdata-flow analysis, ”DrComp”で類似コード抽出
 デバイスの挙動を推測
 ドライバは何をしているか？，ドライバの相互作用，ドライバの冗長性
9 2012/4/25

10. Understanding Modern Device Drivers
 ドライバは何をしているか？
 研究時のドライバの挙動に対する前提を検証
 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%のコードに類似性がある
10 2012/4/25

11. Cosmic Rays Don't Strike Twice: Understanding the
Nature of DRAM Errors and the Implications for System Design
 背景: 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テラバイト・年のメモリを調査
11 2012/4/25

12. Cosmic Rays Don't Strike Twice: Understanding the
Nature of DRAM Errors and the Implications for System Design
 方法: アプリケーションで繰り返しメモリアクセス
 同一カ所の繰り返しエラーを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
12 2012/4/25

13. ELI: Bare-metal Performance for I/O Virtualization
 背景：仮想化環境における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の有無を設定不可能
13 2012/4/25

14. Architectural Support for Hypervisor-secure
Virtualization
 背景: ハイパーバイザの普及
 Amazon EC2等のIaaS型クラウドで活用
 問題: ハイパーバイザからVMを守れるか？
 ハイパーバイザが乗っ取られた時のVMの機密性・完全性維持
 普通はハイパーバイザが全権限を持っている
 提案: hypervisor-secure virtualization (HyperWall)
 CPUを拡張して保護機構を導入する
 CIP (Confidentiality and Integrity Protection) table
 ハイパーバイザやDMAからのページ単位のメモリ保護
 VM終了時のメモリゼロ初期化
 CPU内電子署名による保護状態のチェック
 VMの起動や停止など管理タスクはハイパーバイザが実行
14 2012/4/25