Upgrade to Pro — share decks privately, control downloads, hide ads and more …

HPCS Lab. SSチーム 論文読み会 "The benefits and costs of writing a POSIX kernel in a high-level language"

HPCS Lab. SSチーム 論文読み会 "The benefits and costs of writing a POSIX kernel in a high-level language"

7efb8935d734ad05a38da5682afb36a6?s=128

TAKAHASHI Shuuji

July 03, 2019
Tweet

Transcript

  1. The benefits and costs of writing a POSIX kernel in

    a high-level language 2019-07-03 SSチーム論文読み会 HPCS Lab. SSチーム M1 高橋 宗史 Cody Cutler, M. Frans Kaashoek, and Robert T. Morris, MIT CSAIL 出典: https://blog.golang.org/gopher
  2. 論文について • ページ数: 14ページ • 発表: 13th USENIX Symposium on

    Operating System Design and Implementation (OSDI '18) • 開催日: 2018年10月8日-10日 • 場所: Carlsbad, CA, USA 出典: https://www.booking.com/hotel/us/carlsbad-inn-beach-resort.ja.html
  3. この論文を読むモチベーション • 自分の研究とは直接は関係しない • Goでカーネルを作る話が面白そうだったため選んだ • カーネル実装の話を通して、普段使っているLinuxにより親しめるようになることを 期待 • カーネルを構成する基本コンポーネントを知るのはLinuxを知るためにも有用なは

  4. 注意事項 • 要約するのが下手で、輪講のように長く(40ページ)なってしまいました • 今日紹介するのは、§1 - §4 まで • §5

    - §10 は次回以降です
  5. 論文の構成 1. Introduction ◦ OSのカーネルを実装する言語の概略 ◦ Goで実装したカーネルBiscuitの性能をCのカーネルと比較 2. Related work

    ◦ 4つの観点から関連を紹介 3. Motivation ◦ CとGo(高レベル言語)の利点と欠点を比較し、Goでカーネルを書く価値を確認 4. Overview ◦ Goで実装したカーネルBiscuitの概要を様々な観点から解説
  6. 論文の構成 (cont'd) ↓以下の紹介は次回以降です 5. Garbage collection ◦ ガベージコレクションについて 6. Avoiding

    heap exhaustion ◦ ヒープの枯渇問題に対処した話 7. Implementation ◦ 実装したコードの説明 8. Evaluation ◦ 詳細な評価結果 9. Discussion and future work 10. Conclusions
  7. Abstract • ガベージコレクションを持つハイレベル言語(High Level Language; HLL)を使用し て、モノリシックなPOSIXスタイルのカーネルを実装 ◦ 目的: 実行コスト・実装のチャレンジ・プログラマビリティ・安全性の検証

    • 論文では、十分にPOSIXを実装したカーネルBiscuitをGoで実装 ◦ POSIX: 仮想メモリ・`nmap`・TCP/IPソケット・ログファイルシステム・`poll`など ◦ GoのHLL機能を多用: クロージャ・チャネル・マップ・インターフェイス・ガベージコレクショ ン付きヒープ割当 ◦ 特に、カーネルのヒープメモリ枯渇問題 への対処が 最もchallengingなpuzzleだった
  8. Abstract (cont'd) • 評価: カーネルインテンシブなベンチマークを実施 ◦ NGINX・Redisなどを実行 ◦ 評価結果 ▪

    HLL機能 (主にガベージコレクションとスレッドスタックの拡張のチェック )によるカー ネルCPU時間のfraction (断片化?) = 最大13%増加 ▪ NGINXによるGC関連の最大の停止時間 = 115 μs ▪ クライアントから見たGCのディレイの合計の最大値 = 600 μs ▪ システムコール・ページフォルト・コンテキストスイッチの条件をほぼ同じにして CとGo のカーネルを比較した結果、5% - 15% Goの方が遅かった
  9. 論文の構成 1. Introduction ◦ OSのカーネルを実装する言語の概略 ◦ Goで実装したカーネルBiscuitの性能をCのカーネルと比較 2. Related work

    ◦ 4つの観点から関連を紹介 3. Motivation ◦ CとGo(高レベル言語)の利点と欠点を比較し、Goでカーネルを書く価値を確認 4. Overview ◦ Goで実装したカーネルBiscuitの概要を様々な観点から解説 5. Garbage collection ◦ ガベージコレクションについて
  10. 1. Introduction • 現在の実用的なOSのカーネルはすべてCで書かれている ◦ Linux, macOS, Windows など ◦

    メモリへのアクセス性とメモリ管理の性能の高さ ◦ 一方でメモリ管理はバグの温床にもなっている (2017年の50個のバグの原因) • HLL (High-Level Language) ◦ 抽象化とメモリ安全性を提供 ◦ 新しいアイデアの検証に利用 ◦ 一方で実使用に耐える高性能なカーネルとしての使用は懐疑的に考えられている • しかし、CをHLLでリライトするのは無意味かもしれないが、新しく使用すべき言語を 検証するのは有意義だと考えられる
  11. 1. Introduction (cont'd) • Go で x86-64 向けのカーネル Biscuit を書いた

    ◦ POSIX システムコールのサブセットを実装 ▪ ウェブサーバの NGINX やインメモリの キーバリューストアRedis が実際に動く! ◦ その他多数の機能: マルチコア・カーネル支援ユーザースレッド ・futex・IPC・mmap・copy-on-write fork・vnode・name cache・ロギングファイルシステ ム・TCP/IP ソケット • futexとは? ◦ Linux独自の高速ユーザー空間 mutex (Fast Userspace muTex) ◦ 参考: futex - 約束事その他の説明 - Linux コマンド集 一覧表 - https://kazmax.zpp.jp/cmd/f/futex.7.html 出典: http://download.redis.io/logocontest/ https://www.nginx.com/
  12. 1. Introduction (cont'd) • Goでx86-64向けのカーネルBiscuitを書いた (つづき) ◦ ドライバ ▪ ストレージ:

    AHCI SATAディスクコントローラー ▪ ネットワーク: Intel 82599-based Ethernetコントローラ ◦ コード量 ▪ Goコード: 約28,000行 ▪ アセンブリ: 1546行 ▪ Cコード: 0行 (no C!) ◦ 参考 ▪ 最初のコミット: 約10年前 ▪ 現在までのコミット数: 約39,000コミット ▪ コントリビューター: 約1,000人
  13. 1. Introduction (cont'd) • 設計 ◦ 基本的には伝統的なモノリシックの POSIX/Unixカーネルと同じようなデザイン ◦ Biscuitの設計で優れている点

    ▪ カーネルヒープ枯渇問題に対処するしくみ • HLLの機能を利用した静的解析のおかげで、複雑なメモリ割り当ての失敗や デッドロックからのリカバリが可能になった
  14. 1. Introduction (cont'd) • ベンチマーク ◦ ガベージコレクションなど ▪ ガベージコレクションはCPUの最大3%を使用 ▪

    NGINXではGC関連の停止が 115 μs、クライアント側では 600 μs ▪ その他のHLLのコストはCPUの10% ◦ Cとの比較 ▪ CとGoのシステムコールのコードパスを同等に修正して測定 ▪ Cの方が 5% - 15% 高速 ◦ カーネルインテンシブなアプリケーションベンチマーク ▪ Linuxの方が最大 10% 高速 ◦ Biscuitの方が性能は低いが、十分戦える性能は発揮されている 出典: https://www.vexels.com/png-svg/preview/140692/linux-logo
  15. 1. Introduction (cont'd) • 本研究の貢献 ◦ (1) Goで書いたカーネルBiscuitは優れた性能を発揮したこと ◦ (2)

    カーネルヒープ枯渇問題に対処する優れたスキームを提案したこと ◦ (3) カーネルの実装について HLL が役に立つ場合と役に立たない場合について、定性的 に議論したこと ◦ (4) HLLを使用したことによる性能の負債 (tex)を測定したこと ◦ (5) Go-vs-C の性能を、典型的なカーネルのコードで同等の条件で比較した
  16. 論文の構成 1. Introduction ◦ OSのカーネルを実装する言語の概略 ◦ Goで実装したカーネルBiscuitの性能をCのカーネルと比較 2. Related work

    ◦ 4つの観点から関連を紹介 3. Motivation ◦ CとGo(高レベル言語)の利点と欠点を比較し、Goでカーネルを書く価値を確認 4. Overview ◦ Goで実装したカーネルBiscuitの概要を様々な観点から解説 5. Garbage collection ◦ ガベージコレクションについて
  17. 2. Related work • 1. HLLで書かれたカーネル ◦ Taos・Spin・Singularity・J-kernel・KaffeOS・House・Mirage unikernel・Tock (昔:

    Pilot・Lisp machine) (このSingularityはHPC用のコンテナエンジンではない) • 2. 高レベルシステムプログラミング言語 ◦ 型安全・ガベージコレクション ◦ Go・Java・C#・Cyclone (昔: Cedar・Modula-3) (最近: D・Nim(rod)・Go・Rust) ◦ gVisor ▪ Goで書かれたユーザースペースカーネル ▪ コンテナのサンドボックスとして使用 ▪ Google App Engine Flexible Environmentが可能に ▪ 参考: google/gvisor: Container Runtime Sandbox • https://github.com/google/gvisor
  18. 2. Related work (cont'd) • 3. メモリ割り当て ◦ Rustでは、ガベージコレクションに限界があるという考えのもと、メモリの開放を部分的に 自動化したが、複数スレッドやクロージャでデータを共有するのが面倒になった

    ◦ Biscuitでは、Go 1.10で導入された並列ガベージコレクタを利用
  19. 2. Related work (cont'd) • 4. カーネルヒープの枯渇問題 ◦ Linuxの場合 ▪

    メモリ確保が失敗するまで楽観的にシステムコールを実行 ▪ 失敗した場合はエラーリカバリーを行うが、バグの温床となっている ▪ システムコールが失敗するとほとんどのアプリは動作しなくなる ◦ Biscuitの場合 ▪ reservation approachによりコードがシンプルに ▪ カーネルヒープの割当は失敗しないため、複雑なエラーリカバリーを除去 ▪ 静的解析により利用メモリ量を特定できるため、システムコール発行時に必要な カーネルヒープメモリが確保できる ▪ カーネルヒープメモリが枯渇しても処理が遅延するだけ なので、アプリケーションにはエラーが返らない
  20. 論文の構成 1. Introduction ◦ OSのカーネルを実装する言語の概略 ◦ Goで実装したカーネルBiscuitの性能をCのカーネルと比較 2. Related work

    ◦ 4つの観点から関連を紹介 3. Motivation ◦ CとGo(高レベル言語)の利点と欠点を比較し、Goでカーネルを書く価値を確認 4. Overview ◦ Goで実装したカーネルBiscuitの概要を様々な観点から解説 5. Garbage collection ◦ ガベージコレクションについて
  21. 3. Motivation • CとGoの利点と欠点を比較し、Goで実装する利点を確認する • Cの利点 ◦ 人気の主な理由は性能向上に利用できる低レベルの操作 ▪ 特に、ポインタ演算・型強制の除去・明示的なメモリ割り当て・カスタムアロケータ

    ▪ ハードウェアレジスタを簡単に操作できるなどの理由もあるが、一番の理由は性能
  22. 3. Motivation • Cの欠点 ◦ さまざまなバグの温床 ▪ バッファオーバーランのバグ ▪ use-after-freeバグ

    • メモリ領域をfreeした後に誤って使用してしまうバグ ▪ Cの型の強制の緩和によるバグ ◦ 特にuse-after-freeバグはCのプロでも日常茶飯事 ▪ 2018年1月〜4月だけでuse-after-freeバグに関する修正が少なくとも36コミットも ◦ 参考: CERT C コーディングスタンダード https://www.jpcert.or.jp/sc-rules/
  23. 3. Motivation (cont'd) • HLLの利点 ◦ 様々な恩恵 ▪ メモリ管理から解放・メモリ解放のバグを回避・型安全性によるバグの発見・実行時 の型付けとメソッドディスパッチ

    ▪ スレッドと同期を言語がサポートしているため、 Cより並行プログラミングがずっと簡 単 ◦ バグの回避 ▪ 前スライドで挙げたCの欠点を回避できる ▪ CVEデータベースに2017年に登録されたLinuxカーネルの40個のバグの多くが、 HLLであれば回避できた
  24. 3. Motivation (cont'd) • HLLの欠点 ◦ 特に以下はCPU時間を消費し、遅延を引き起こす ▪ ガベージコレクション ▪

    型安全性のチェック ◦ 高レベルな機能は高く付く ◦ 言語ランタイムがメモリ管理の重要なメカニズムを隠してしまう ◦ 抽象と安全性の代償として、実装の選択肢が狭まる
  25. 論文の構成 1. Introduction ◦ OSのカーネルを実装する言語の概略 ◦ Goで実装したカーネルBiscuitの性能をCのカーネルと比較 2. Related work

    ◦ 4つの観点から関連を紹介 3. Motivation ◦ CとGo(高レベル言語)の利点と欠点を比較し、Goでカーネルを書く価値を確認 4. Overview ◦ Goで実装したカーネルBiscuitの概要を様々な観点から解説 5. Garbage collection ◦ ガベージコレクションについて
  26. 4. Overview • Biscuitの主目的 ◦ HLLでカーネルを書く実用性の評価 • UNIX-likeなモノリシックカーネル ◦ Cのカーネルと比較を簡単にするため

    • 64-bit x86 ハードウェアで実際に動作 • Go 1.10 + 以下のアセンブリで記述 ◦ bootのためのコード ◦ システムコールのentry/exit ◦ 割り込みコード
  27. 4. Overview (cont'd) • 以降、8つのポイントごとにBiscuitの設計について紹介する ◦ ブートとGoランタイム ◦ プロセスとカーネルのGoルーチン ◦

    割り込み処理 ◦ マルチコアと同期 ◦ 仮想メモリ ◦ ファイルシステム ◦ ネットワークスタック ◦ Biscuitの制限事項
  28. 4. Overview (cont'd) • ブートとGoランタイム ◦ ブートブロックがBiscuit・Goランタイム ・"Shim"の3つを読み込む ◦ 通常Goランタイムは、特にメモリ割り当て

    と実行コンテキスト(Goルーチン)の制御を カーネルに移譲するが、今はカーネルは 存在しないのでShimが処理を代行する ◦ Shimの処理の大部分は初期化段階で行 われる (Goカーネルのヒープの pre-allocate など)
  29. 4. Overview (cont'd) • プロセスとカーネルのGoルーチン ◦ BiscuitはPOSIXインターフェイス(forkや execなど)でユーザープロセスを提供 ◦ 1ユーザープロセス

    = 1アドレス空間 + 1つ 以上のスレッド ◦ ハードウェアレベルのページ保護でユー ザープロセスを隔離 ◦ ユーザープログラムはどんな言語でも記 述OK (論文ではCとC++のみを使用した not Go)
  30. 4. Overview (cont'd) • プロセスとカーネルのGoルーチン (cont’d) ◦ Biscuitはユーザースレッドごとに対応する Goルーチンを1つ生成 ◦

    ユーザースレッドのシステムコールと、 ページフォルトや例外のハンドラを実行す る ◦ (注釈: 「Goルーチン」とはGo特有のスレッ ドのこと。この論文では、Goルーチンとは、 カーネル内で実行されるスレッドのみを指 す)
  31. 4. Overview (cont'd) • プロセスとカーネルのGoルーチン (cont’d) ◦ Biscuitランタイムがユーザープロセスに対 応するカーネル内のGoルーチンをスケ ジューリングする

    ◦ タイマー割り込みを用いてユーザースレッ ドを先制して(pre-emptively)スイッチ ◦ Goコンパイラが生成した、カーネル Go ルーチンを先制(pre-emption)チェックす るコードを使用
  32. 4. Overview (cont'd) • 割り込み処理 ◦ Biscuit のデバイス割り込みハンドラが関連するデバイスドライバの Go ルーチンを「実行

    可能 (runnable)」とマークして return するだけ (先行研究による) ▪ Goルーチンのコンテキストスイッチなど、センシティブな操作中に Go ランタイムが止 められないため、それ以上のことをしようとするとデッドロックのリスクが生じる (?) ◦ ユーザー空間から渡されたシステムコールやフォールトのハンドラは任意の Goコードを実 行できる。Biscuitはユーザースレッドに対応するGoルーチンのコンテキストでGoコードを 実行する
  33. 4. Overview (cont'd) • マルチコアと同期 ◦ Biscuit はマルチコアハードウェア上で並列に実行される ▪ Go

    の mutex がデータ構造を保護し、 ▪ Go のチャネルと条件変数で同期を実現する ◦ 細かい粒度でロックが行われるため、別のコアのスレッドのシステムコールが多くのシ チュエーションで並列に実行される ▪ 例: 異なるファイル・パイプ・ソケットに対する操作、 別プロセス上にフォークして実行される場合など ◦ performance-critical なコードでは、後述の read-lock-free ルックアップを活用している
  34. 4. Overview (cont'd) • 仮想メモリ ◦ ページテーブルハードウェアを活用することで以下の機能を実現 ▪ zero-fill-on-demand なメモリ割り当て

    ▪ copy-on-write `fork()` ▪ プロセスがページフォルトしたときのみ PTE (Page Table Entry) を populate する、 ファイルの lazy mapping の機能 (例: `exec()`などの実行時) ▪ `mmap()`
  35. 4. Overview (cont'd) • 仮想メモリ (cont'd) ◦ 参考資料: ▪ PTE

    とは? • 情報科学類「オペレーティングシステム II」メモリ管理 http://www.coins.tsukuba.ac.jp/~yas/coins/os2-2018/2019-01-17/inde x.html ▪ copy-on-write とは? • コピーオンライト - Wikipedia - https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%94%E3%83%BC%E3 %82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%88
  36. 4. Overview (cont'd) • ファイルシステム ◦ 主要な POSIX ファイルシステムコールに対応したファイルシステムを実装 ◦

    3種類のキャッシュを実装 ▪ ファイル名の lookup キャッシュ ▪ vnode cache ▪ ブロックキャッシュ ◦ 各 vnode を mutex でガードし、read-lock-free のディレクトリキャッシュの最初のルック アップでパスを解決する ◦ 各ファイルシステムコールをトランザクションとして処理し、コミットのジャーナルは自動的 にディスクに反映される
  37. 4. Overview (cont'd) • ファイルシステム (cont'd) ◦ ◦ AHCI ディスクドライバを利用して以下の機能を実行可能

    ▪ DMA (ダイレクトメモリアクセス) の使用 ▪ command coalescing (コマンドの結合)? ▪ ネイティブコマンドキュー ▪ MSI 割り込み?
  38. 4. Overview (cont'd) • ネットワークスタック ◦ 以下のネットワーク関連スタックを実装 ▪ TCP/IP スタック

    ▪ Intel PCI-Express Ethernet NIC に対するドライバ (Goで実装) ▪ DMA および MSI 割り込みを使用するドライバ ▪ POSIX ソケットを提供するシステムコール API
  39. 4. Overview (cont'd) • Biscuitの制限事項 ◦ 多くのCプログラムがソースコードそのままで実行できるが、研究用のプロトタイプなので 多くの機能が不足している ◦ Goランタイムのスケジューラに依存しているため、優先度付きスケジューリングに対応し

    ない ◦ 少数コアに最適化されているため、多数コアマシンや NUMAアーキテクチャには適さない ◦ ディスクへの swap out や page out を行わない ◦ reverse mapping (?) を実装していない ◦ セキュリティ機能の多くを提供しない ▪ ユーザー・ACL (Access Control List)・ アドレス空間ランダム化など
  40. リンク集 • mit-pdos/biscuit: Biscuit research OS - https://github.com/mit-pdos/biscuit ◦ Biscuit

    のソースコード
  41. The benefits and costs of writing a POSIX kernel in

    a high-level language 2019-07-17 SSチーム論文読み会 HPCS Lab. SSチーム M1 高橋 宗史 Cody Cutler, M. Frans Kaashoek, and Robert T. Morris, MIT CSAIL 出典: https://blog.golang.org/gopher (第2回)
  42. 注意事項 • 今日紹介するのは、§5. Garbage collectionと §6. Avoiding heap exhaustion だ

    けです • スライドは 27 枚 (前回は 40 枚) • §7 - §10 は…?
  43. 5. Garbage collection • Goのコレクタの設計 ◦ Go1.10から並行・並列 mark-and-sweepGC が実装された ◦

    これにより、stop-the-world による停止 が最小化されるようになった 出典: Tracing garbage collection - Wikipedia 普通の mark-and-sweep の例
  44. 5. Garbage collection • 並列GCの動作のしくみ ◦ メモリ空き容量がしきい値以下になると GC が有効になり以下を実行 ▪

    1)ポインタのトレース ▪ 2)使用済みオブジェクトのマーク ◦ さらに、実行中にGC以外の通常の命令を インターリーブさせる ◦ トレース済みのオブジェクトに対して、コン パイラが「writeバリア」を生成するため、イ ンターリーブ中にポインタが新しくできても 区別してトレースが可能 出典: Tracing garbage collection - Wikipedia 普通の mark-and-sweep の例
  45. 5. Garbage collection (cont’d) • 「stop-the-world」pauseが発生する2つのタイミング ◦ 1) 最初に全コアがwriteバリアを張るとき ◦

    2) 最後にすべてのオブジェクトがマークされたかをチェックすると き ◦ これらによる停止時間は数 10 μs 程度 • CPUの消費時間 ◦ live オブジェクトの数に比例 ◦ GC の実行間隔に反比例 ▪ 実行間隔は潤沢なRAMをヒープに割り当てると大きくなる ◦ 測定結果は §8.5 で紹介する 出典: Craftprokits Clock Insert 69mm | Axminster Tools & Machinery
  46. 5. Garbage collection (cont’d) • Go ランタイムのヒープメモリ ◦ Biscuit では

    RAM の 1/32 を固定で割り当てている • Go の GC ◦ デフォルトでは、空き容量が 1/2 以下になるとヒープが自動拡 張されるが、Biscuit ではこの機能を無効化している ◦ 次の §6 では、ヒープメモリの空き容量が枯渇してきたときに、 Biscuit がどのように対処しているかを詳しく解説する 出典: Craftprokits Clock Insert 69mm | Axminster Tools & Machinery
  47. 6. Avoiding heap exhaustion • Biscuit はカーネルデータによるヒープの枯渇を回避する必要がある • 様々なカーネルが問題に取り組んできた難しい領域 (§2)

    • このセクションの目次 ◦ 6.1 Approach: reservastion ◦ 6.2 How Biscuit reserves ◦ 6.3 Static analysis to find s ▪ 6.3.1 Basic MaxLive operation ▪ 6.3.2 Handling loops ▪ 6.3.3 Kernel threads ▪ 6.3.4 Killer thread ◦ 6.4 Limitations ◦ 6.5 Heap exhaustion summary 出典: 主記憶装置 - Wikipedia
  48. 6.1 Approach: reservation • Biscuit では、カーネルヒープが枯渇しても動作し続 けるように設計されている ◦ カーネルリソースを過剰に消費する悪い市民 ("bad

    citizen" process) が発見されると kill する ◦ ヒープの空きを確保することで良い市民 ("good citizen") が動作し続けられるようにする 出典: Smushie Ranch: Gunther taken out by killer gopher
  49. 6.1 Approach: reservation (cont’d) • ヒープ枯渇の対処の3つのアプローチ ◦ 1) キャッシュと soft

    state をパージする ◦ 2) システムコールの実行前に必要なヒープが確保で きるまで wait する ◦ 3) killer thread がヒープを過剰消費している悪い市 民を kill する 出典: Smushie Ranch: Gunther taken out by killer gopher
  50. 6.1 Approach: reservation (cont’d) • このアプローチの利点 ◦ ヒープ枯渇によるシステムコールの失敗の可能性が 0、アプリケーションがクラッシュしない ◦

    (基本的には)カーネル内ではヒープ・アロケーション の失敗に対処する必要がない ◦ システムコールの途中で失敗からリカバリーするコー ドが不要になる 出典: Smushie Ranch: Gunther taken out by killer gopher
  51. 6.1 Approach: reservation (cont’d) • killer による良い市民/悪い市民の判別問題 ◦ たとえば killer

    が init を kill したら困る ◦ Kernel が安全にリソースを取り消す (gracefully revoke) 手段が POSIX で定義されていないせいで、 特定のメモリ不足の状況下で適切な解決方法が見つ からない 出典: Smushie Ranch: Gunther taken out by killer gopher
  52. 6.2 How Biscuit reserves • システムコールで必要なカーネルヒープメモリ容量について考える ◦ M: Biscuit が固定で確保するカーネルヒープメモリの容量

    ◦ s: 全データがヒープメモリを同時に使用する最大値 ▪ システムコールの実行時に計算される ◦ 理想的には、利用可能な領域は M - s で求まる ▪ しかし、使用中の領域の GC 後の正確な値が不明! 使用中の領域 必要なヒープメモリの最 大値 s カーネルヒープメモリ M GC後の正確な値??
  53. 6.2 How Biscuit reserves (cont’d) • 使用中の領域を多く見積もるために g, c, n

    という3つのパラメータを管理 ◦ g: 前回のGCで mark されたデータ (= また使用中の可能性が残っているデータ ) ◦ c: 完了済みのシステムコールで予約されたデータの合計 ◦ n: 実行中で未完了のシステムコールで予約されたデータの合計 • L をこれらの合計として次のようにおく。 ◦ L = g + c + n 使用中の領域 必要なヒープメモリの最 大値 s カーネルヒープメモリ M GC後の正確な値??
  54. 6.2 How Biscuit reserves (cont’d) • システムコールの開始時 reserve(s) • スレッドが

    L + s < M をチェック ◦ 使用済みL + 新規メモリs < 合計M • L + s < M の場合 (メモリが足りる) ◦ n += s して、新しいシステムコール用 にメモリを確保する • otherwise (メモリが足りない) ◦ killer を起こして、悪い市民を殺し終 わるまで待機する // カーネルヒープメモリの予約 reserve(s): g := 最終 GC 時の有効バイト数 c := 使用済みバイト数 n := 予約済みバイト数 L := g + c + n M = ヒープメモリのバイト数 if L + s < M: 予約済みバイト数 += s else: killer スレッドを起こす killer が悪い市民を殺すまで待機する
  55. // カーネルヒープメモリの開放 release(s): a := システムコールで割り当てられたバイト数 if a < s:

    使用済みバイト数 += a else: 使用済みバイト数 += s 予約済みバイト数 -= s ・c = 使用済みバイト数 ・n = 予約済みバイト数 6.2 How Biscuit reserves (cont’d) • システムコールの終了時 release(s) • システムコールが実際に割り当てられ たメモリの合計 a の値を計算 • a < s の場合 ◦ c += a • a ≧ s の場合 ◦ c += s • 最後に ◦ n -= s
  56. 6.3 Static analysis to find s • MaxLive というツールを作成した ◦

    Biscuitのソースコード+使用しているGoパッケージを解析し、 ◦ システムコールが必要とするヒープメモリ量 s を計算する • 難しかった点1 ◦ 多くのシステムコールはメモリを一時的にしか割り当てない ◦ そのため、割当メモリが使用されなくなったことを静的に検出するのが大変 • 難しかった点2 ◦ 上限が不定のループの解析 • 難しかった点3 ◦ システムコールと無関係のバックグラウンドのカーネル アクティビティによるメモリ割り当て量の特定
  57. 6.3 Static analysis to find s (cont’d) • イベントハンドラスタイルというカーネルの特性を活用 ◦

    様々な作業が実行されたあと、return するというスタイル ◦ システムコールもこのように実装されている • 解析しやすいように追加の修正も行った ◦ 再帰がなくなるように数カ所の関数を修正 ◦ Goパッケージを一部修正 (time と fmt)
  58. 6.3.1 Basic MaxLive operation • MaxLive ◦ コールグラフをチェック ▪ システムコールが実行する可能性のあるすべてのメモリ割り当てを検出

    • Go の ssa および callgraph パッケージを活用 ◦ エスケープとポインタ解析を利用 ▪ エスケープしない := コールグラフでそれ以上先まで呼び出しがないこと • Go の pointer パッケージを活用
  59. 6.3.1 Basic MaxLive operation (cont'd) • 参考リンク ◦ callgraph -

    GoDoc - https://godoc.org/golang.org/x/tools/go/callgraph ◦ TrueFurby/go-callvis: Visualize call graph of a Go program using dot format. - https://github.com/TrueFurby/go-callvis ◦ ssa - GoDoc - https://godoc.org/golang.org/x/tools/go/ssa ▪ ssa = 静的単一代入 ◦ pointer - GoDoc - https://godoc.org/golang.org/x/tools/go/pointer
  60. 6.3.1 Basic MaxLive operation (cont'd) • MaxLive ではいくつかの割り当てを特別扱いしている ◦ go

    (goroutine を作る) ▪ カーネルスタックサイズの最大値を割り当てる ◦ defer ▪ 普通の呼び出しだが、SSA では object として表現されるた め、メモリ割り当てとみなす ◦ map & slice への insert ▪ 一般に挿入前のサイズが検知できないため、メモリ割り当て 料が予測できない ▪ この問題に対処するため、map と slice の最大値のアノテー ションを Biscuit のソースコード70箇所に追加した
  61. 6.3.2 Handling loops • MaxLive が実用的なループ回数を特定できない箇所 ◦ ソースの78箇所にアノテーションを追加した ◦ さらに20箇所はアノテーションが困難

    ▪ 例1) wakeup race を扱う retry が必要な poll() システムコール ▪ 例2) path のルックアップをしながらディレクトリのデータブロックのイテレーションを する部分 ▪ 例3) ユーザーバッファのページをイテレーションする必要がある write() システム コール
  62. 6.3.2 Handling loops (cont'd) • 対処方法: deep reservation ◦ 1回のイテレーションに必要なだけのヒープのみ

    reserve する ◦ メモリが確保できなかった場合、一度 abort してメモリ確保を待機、システムコールの最 初からリトライする ◦ exec() と rename() のみ、割り当て失敗時に undo を行うコードを書かざるを得なかった が、他のシステムコールはリカバリコードは不要になった
  63. 6.3.2 Handling loops (cont'd) • exit()、fork()、exec() の問題 ◦ 多数のファイルディスクリプタを close()

    する可能性がある ◦ ファイルの close 時にはファイルシステムの更新の可能性あり ▪ ファイルシステムが割り当てメモリに書き込み ▪ ファイルシステムキャッシュにエントリを作成 ◦ 多数のファイルを close → 1回の exit() で大きなヒープメモリを使用するかも • 対処方法 ◦ MaxLive で close() の1回の呼び出しでのメモリ使用量の解析 ◦ さらに手動で、「close() 呼び出し後に割り当てを破棄すること」 OR「破棄可能なキャッシュエントリで行われること」を保証 ◦ 必要ヒープメモリを close() 1回分のヒープのみに修正
  64. 6.3.2 Handling loops (cont'd) • 最終的な成果 ◦ rename() と fork()

    以外のすべてのシステムコールのヒープ使用量の上限を 500kB 以下に抑えることに成功 ▪ rename() = 1MB ▪ fork() = 641kB ◦ MaxLive を使用して手動で解析が必要だったのは close() だけ ▪ 残りはすべて自動で解析ができた!
  65. 6.3.3 Kernel threads • カーネル領域 ◦ 長時間実行が継続されるカーネルスレッドそれぞれに対しても、カーネルヒープの reservation が必要 ▪

    exit() はkiller スレッドがプロセスを kill するときに動作する必要があるため、 exit() が依存しているカーネルスレッドは、自分が持っているヒープを勝手に解放できない ◦ 例) exit はファイルやブロックを削除するため、ファイルシステムロギンススレッドが必要
  66. 6.3.4 Killer thread • システムコールメモリ割り当て失敗時に目覚める a. ガベージコレクションの実行 b. 不十分な場合、キャッシュなどを開放し、再度、ガベージ コレクションを実行

    c. それでも不十分な場合 ▪ メモリ領域・ファイルディスクリプタ・スレッドを最も 多く持っているプロセスを探し出す ▪ このプロセスを「真に悪い市民 (genuine bad citizen)」であると推定する ▪ その市民を kill する ▪ 再度、ガベージコレクションを実行 d. メモリ割り当てに満足したら、眠る
  67. 6.4 Limitations • 1) Biscuit のヒープ枯渇問題への対処には、メモリ枯渇時にGCが正常に動作する ことが必要 ◦ Goのガベージコレクタは動作時に新規メモリ割り当てが必要なため問題 ◦

    まだ未実装だが、Biscuit はこの状況から回復可能 (ただし、遅くなることが予想される ) ◦ そもそもこの状況は稀であり、実験によれば、 GC は 最大でも 0.8% のヒープメモリを work stack に割り当てれば十分 • 2) Go の GC はオブジェクトを移動させないため、フラグメンテーションが削減されな い ◦ MaxLive でシステムコール時のヒープの割り当て時にオブジェクトの種類ごとに s を推定 することでリスクを減らせるが、まだ未実装
  68. 6.5 Heap exhaustion summary • Linux のアイデアを採用した ◦ killer thread

    ◦ waiting & retry • Linux ではメモリ割り当ての段階でチェックするのに対して、Biscuit では、システム コールの呼び出し前に都度、チェックするように変更した • これにより、リカバリーコードを減らすことができ、メモリ割り当てのデッドロックの回 避が可能になった • さらに、Goの静的な解析を利用することで、この手法の自動化も可能になった
  69. §6 Fin.