A Framework for Easily and Efficiently Extending Operating Systems OSの機能拡張を容易にかつ効率よく 行なうための枠組 益田研究室 修士２年 光来健一 拡張可能ＯＳ • ＯＳの拡張に対する要求が高まっている – 機能拡張 • 新しいネットワークプロトコルを追加する 例： ＩＰｖ６ – 性能向上 • データベース専用のファイルシステムを使う 例： ファイルキャッシュのポリシにＬＲＵを使わない • 拡張可能ＯＳが研究されている – ＯＳを拡張するためのプログラム（拡張モジュール）を 動的に追加できる fail‐safe機構 • 拡張モジュールのエラーからＯＳを守る必 要がある – 拡張モジュールは意図しない動作をするかも しれない • fail-safe機構の役割 – 拡張モジュールのエラーを検出する – エラーの検出された拡張モジュールをＯＳから 安全に切り離す 従来のアプローチの問題点 • fail-safe機構は性能を犠牲にするので、両 者のトレードオフを取るのは難しい – 拡張モジュールをloadable kernel moduleとして 作る – 拡張モジュールをユーザプロセスとして作る (Mach[Accetta et al.86]) – 拡張モジュールにload/store/jumpのアドレスを 検査するコードを挿入する （VINO[Selzer et al.96]) fail‐safe機構に関する考察 • 常に完全なfail-safe機構が必要なわけで はない – 保護レベルは段階的に変えられた方がよい 例１．拡張モジュールの使用 • 不安定な場合は必要な保護をして使う • 安定している場合は保護をせずに使う 例２．拡張モジュールの開発 1. デバッグ時には十分に保護する 2. βテスト時には保護を弱めて性能を良くする 3. リリース時には保護なしで動かせるようにする 多段階保護機構の提案 • 拡張モジュールを様々な保護レベルでＯＳ に組み込むことができる – 安定度に応じて性能とfail-safeの能力のトレー ドオフを取ることができる 保護レベル 高 低 不安定な拡張モジュール やや不安定な拡張モジュール 安定な拡張モジュール カーネル 性能 悪 カーネル カーネル 良 システム構成 • 多段階保護機構を実現す るシステム 拡張モジュール – 保護マネージャ • fail-safe機構を実現する • 拡張モジュールとリンクされる ライブラリ • 複数用意されている • それぞれが様々な保護レベル を提供する – 適切な保護マネージャを選 ぶことができる 保護マネージャ カーネル 保護マネージャ • 拡張モジュールとカーネ ルの間のゲートウェイの 役割を果たす – カーネルからのアップ コールを中継する – 拡張モジュールにカーネ ルデータを安全に操作さ せる 拡張モジュール カーネルデータ の操作 コールバック 保護マネージャ システム コール アップコール カーネル 保護レベルの変更 • 保護レベルの変更は保護マネージャの交換に よって行なう – 拡張モジュールのソースコードを変更したり、再コン パイルしたりする必要はない 高 保護マネージャ１ 拡張モジュール 保護レベル 保護マネージャ２ 保護マネージャ３ 低 共通のＡＰＩ • すべての保護マネージャが共通のＡＰＩを提供す ることで交換を容易にする – それぞれの保護マネージャの実装の違いを吸収する • ＡＰＩの種類 – コールバックのためのＡＰＩ • カーネルからのアップコールによって呼び出される – カーネルデータをアクセスするためのＡＰＩ • 抽象度の高いデータ構造を見せる 様々な保護レベルの実現 • 保護マネージャは以下の保護技術を組み 合わせて様々な保護レベルを提供する – 不正メモリアクセスの検出 • 拡張モジュールをユーザ空間に配置するかどうか • カーネルデータのあるメモリを保護するかどうか • カーネルデータを複製･検査するかどうか – デッドロックの検出 • どのくらいの頻度でデッドロックの検査をするか 保護技術の組合せの例 （ａ）最大の保護レベル 直接 （ｂ）中間の保護レベル 拡張 モジュール ＡＰＩ 拡張 モジュール 保護 マネージャ１ 複製 保護 マネージャ２ カーネル データ カーネル •ユーザ空間 •メモリ保護 •カーネルデータ複製 （ｃ）最小の保護レベル ＡＰＩ カーネル データ カーネル カ ー ネ ル 拡張 モジュール 保護 マネージャ３ •ユーザ空間 •カーネル空間 カーネルによるエラー回復 • 拡張モジュールのエラーを検出したら、 カーネルからエラーの影響を取り除く – 不正メモリアクセスを検出した場合 • 以後そのモジュールを参照しないようにする • ログを元に安定な状態に戻す – カーネルの状態を不安定にする操作についてはログを とっておく – デッドロックを検出した場合 • wait-for-graphのループを破壊する 実験 • 多段階保護機構を実現するシステムCAPELAを NetBSDをベースにして実装した • 実験の目的 – 保護レベルに応じて性能が良くなることの確認 – 最大の保護レベルのオーバヘッドの測定 – ＡＰＩを共通にすることによるオーバヘッドの測定 • 実験環境 – ＰＣ（PentiumII 400MHz) ２台 – 10Mbpsイーサネット 実験対象 • 対象 – ファイルシステム： ＭＦＳ（Memory File System）、ＮＦＳ • 64KBのファイルのコピーに要する時間を測定 – ネットワーク･サブシステム： ＵＤＰ、ＴＣＰ • 往復のレイテンシとスループットを測定 • 表の５つの保護レベルとカーネルに直接作り込 んだものについて実験した 1st メモリ保護 カーネルデータの複製 アドレス空間の切替え 2nd 3rd 4th 5th ：読み出し専用 にして保護 結果： ファイルシステム （コピーに要する時間） – ＭＦＳ： 210% – ＮＦＳ： 70% 50 40 Time (ms) • 最大の保護レベルの オーバヘッド ＭＦＳ 40 30 23.8 19.9 20 12.3 11.8 10 0 • ＡＰＩを共通にすること によるオーバヘッド 600 Time (ms) – ＭＦＳ： 3.7% – ＮＦＳ： 1.4% 38.1 1st 2nd 490 500 3rd 5th hand 315 288 284 4th 5th hand ＮＦＳ 361 400 4th 200 0 1st 2nd 3rd 結果: ネットワーク･サブシステム （往復のレイテンシ） – ＵＤＰ： 180% – ＴＣＰ： 220% 1000 Latency (us) • 最大の保護レベルの オーバヘッド 800 493 459 600 400 294 263 5th hand 440 428 5th hand 200 0 • ＡＰＩを共通にすること によるオーバヘッド 1st 1500 Latency (us) – ＵＤＰ： 12% – ＴＣＰ： 2.8% ＵＤＰ 829 821 2nd 3rd 1410 ＴＣＰ 1198 1000 4th 684 610 500 0 1st 2nd 3rd 4th 結果: ネットワーク･サブシステム （スループット） • 最大の保護レベルの オーバヘッド • ＡＰＩを共通にすること によるオーバヘッド – ＴＣＰ： 1.3% Throughput (Mbps) – ＴＣＰ： 10% ＴＣＰ 8 6.38 6.44 6.91 6.96 7.04 7.13 6 4 2 0 1st 2nd 3rd 4th 5th hand ソースコード変換による性能向上 • OpenC++[Chiba95]を使いソースコード変換をした – ＡＰＩを共通にするためのオーバヘッドを減らす • カーネルが使うデータ構造と拡張モジュールが使うデータ構造 の変換など – 変換前の約半分 ＵＤＰの往復のレイテンシ 400 Latency (us) • ＵＤＰでは変換した後 のオーバヘッドは6.1% に抑えられる 300 294 279 263 5th translated hand 200 100 0 関連研究 • Chorus[Rozier et al.88] – ユーザレベルサーバをカーネルに入れること ができる – カーネルに入れた時の性能が不十分 • ファイルの読み出しで80%のオーバヘッド • SPIN[Bershad et al.95] – 型安全な言語Modula-3を使って拡張モジュー ルを記述する まとめ • 多段階保護機構を提案した – 拡張モジュールを変更なしに様々な保護レベ ルでＯＳに組み込める • CAPELAを実装し、実験によって多段階保 護機構の有用性を確かめた – 不安定な時は許容範囲内のオーバヘッドで十 分な保護ができる – 安定している時はカーネルに作り込んだもの に十分近い性能が得られる 今後の課題 • カーネルレベルでも様々な保護レベルを提供す る – タイミング依存のエラーの検出など • いつ保護レベルを変えるべきかの指針を示す – モジュールの安定度に応じて自動的に保護レベルを 変える • 拡張モジュール間のやりとりを効率よくできるよう にする – ＯＳの拡張モジュールという特徴を活かす
© Copyright 2024 ExpyDoc
