ASPLOS 2012 出張報告

東京大学情報基盤センター

品川高廣

ASPLOS 2012概要（１）

The 17th International Conference on Architectural Support for

Programming Languages and Operating Systems

第１回は1982年，2008年までは隔年，2009年から毎年開催

2012/4/25 2

ASPLOS 2012概要（２）

The Royal Society （王立協会）, London, UKで開催

2012/4/25 3

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

ASPLOS 2012概要（４）

会場（オープニング時の様子）

昼食

2012/4/25 5

紹介論文

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

(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

(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

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”で類似コード抽出

デバイスの挙動を推測

ドライバは何をしているか？，ドライバの相互作用，ドライバの冗長性

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%のコードに類似性がある

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テラバイト・年のメモリを調査

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

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の有無を設定不可能

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の起動や停止など管理タスクはハイパーバイザが実行