by shigemk2

当面は技術的なことしか書かない

カーネル/VM探検隊@つくばに行ってきてLTをやった #kernelvm

とても眠いので、今日あったことを淡々としゃべる。

LTやってきた

超ハイレベルな勉強会で、BrainfuckのEXEコンパイラを作った小噺をしてきた。

おおまかな概要

  1. EXEファイルをhexdumpしてNode.jsで写経
  2. すでに存在するEXEコンパイラなどを駆使してNode.jsでBrainfuckのEXEコンパイラを作る(x86用)
  3. x86版をアレンジしてSH-3用のEXEコンパイラを作る

という内容。およそ10分じゃ足りなかった。

もっと話したかったこと

  • 場所が筑波大なので、国際出であることとか、自分の名前とか、もっとアピールしておけばよかった(自分は文系なので)
  • sh-elf-gccとsh-elf-objdumpのコンボでSH-3のアセンブラを確認しながらEXEファイルを実装したこと

このあたりをうまく、面白おかしく説明出来ればもっと良いLTが出来たのになと反省してる。

以下、小並感

https://pbs.twimg.com/media/B0PEFWuCYAAi1Zt.jpg

自分がエンジニアを志してから、筑波大でエンジニアとして何かしゃべることが夢のひとつでした。本当は国際生の前でしゃべるのがベストでしたが、曲がりなりにもその夢は叶ったので、これで思い残すことがひとつ消えました。

大学生の頃はプログラミングなんて全然やっていなくって、学生時代の大半をこの部屋で本を読んで過ごしていました。所謂ぼっちです。

振り返ってみると自分の学生生活はあまり実りのあるものではなく、帰りのバス、暗闇の中で学生時代のことが走馬灯のように蘇ってきて、とても嫌な気分になりました。

ここ数カ月間Brainfuckでごにょごにょしていましたが、博士号にも乗れたことですし、本業の8086移植に戻ろうと思います。

FreeBSD NFSおさらい

  • サーバ クライアント 通信を行う
  • 状態を保持しないステートレスな通信
  • しかしロックできないと不便なので、rpc.lockdというロック専用のデーモンが管理している
  • 例として、ファイル削除の通信が行わて、途中で通信が切れた場合、もう一度ファイル削除の通信を送るので、直近の通信情報を残しているリストがあって、そのリストを基にクライアントへ情報を送る
  • rpc.statd NFSは基本的な機能だけ持っていて、他のいろいろな機能はデーモンに任せてある
  • UDPではなくTCPを使う

9.3 性能向上のための技術

性能向上は大きな課題

同期書き込みから遅延書き込みへ

  • 短縮 削除
  • 書き戻し処理を完全に止めることも出来る→クライアントの時間の短縮

遅延書き込みにも問題

  • 一貫性の提供
  • エラーの伝達に問題
  • ローカルにキャッシュしててディスクがいっぱいになったら、ファイルはクローズしているのでデータは永遠に失われる
  • fsyncをあちこちやると面倒

http://linuxjm.sourceforge.jp/html/LDP_man-pages/man2/fsync.2.html

折衷案 非同期書き込み

  • 同期 完全に処理が終わってから通信すうr
  • 遅延 データをキャッシュに書き込んで、キャッシュの情報をサーバに送る
  • 非同期 キャッシュに書き込みつつ、アプリに対しての結果通知とサーバに対する通信を同時に行う

Sprite

http://en.wikipedia.org/wiki/Sprite_(operating_system)

NFSは独自方式

非同期書き込みと遅延書き込みの組み合わせ

キャッシュを使うたびに内容を確認し、さらにサーバへ確認する キャッシュの記録時刻とサーバから帰ってきた時刻が一致すればキャッシュのデータを使い、一致しなければキャッシュを更新

RPC要求が押し寄せてくるので遅い

コールバック

サーバがクライアントがキャッシュしているすべてのファイルを管理する

  • 要求の数が劇的に減った
  • サーバが状態を保持しないといけない

FreeBSD

  • ファイルオープン時には非同期書き込みで、書き戻されるのを同期的に待機する

9.3.1 リース

P445

NQNFSプロトコルは、耐障害性の高い方法でクライアント間でキャッシュの完全な一貫性を管理するために設計

リース

  • 一定期間の使用を許すためのチケット
  • クライアントが有効なリースを保持している間は、ファイルの状態が更新されると、サーバはクライアントをコールバック
  • 一定期間その情報を信用していいよっていう許可
  • 期限切れの場合、クライアントはキャッシュ上のデータを使う前にサーバに確認
  • リースは絶対時間ではなく期間指定(RTCが同期していなくても動作するため)

クロックゆらぎ

  • リース期間に与えられる値

書き込み猶予

  • クライアントがダーティデータを書き戻すのに与える猶予期間

期限切れ

  • 期間切れの場合はサーバに問い合わせる
  • 数秒ごとにデータの有効性を確認する
  • リース状態の復帰は容易
  • リース期間は長めなので、サーバへの問い合わせ回数はAndrewファイルシステム並に少ない
  • メモリ消費量も少ない

有効なリース

  • キャシュ不可(ファイル操作がサーバと同期)
  • 読み込みキャッシュ(データのキャッシュは出来るがファイルの内容は変更出来ない)
  • 書き込みキャッシュ(リースが効いている場合はファイルの内容を変更出来る)

不整合

不整合が発生する場合には、クライアントのキャッシュを無効化することで、NQNFSクライアントとの間での一貫性を維持する

リース取得

http://docs.freebsd.org/44doc/papers/nqnfs.html

11 プロセス間通信

P475

  • 分散マルチプロセスプログラム
  • IPC
  • セマフォ
  • メッセージキュー
  • 共有メモリ
  • ソケットインターフェイス

11.1 プロセス間通信モデル

ソケットがなかったのでオレオレプログラムで互換性がないため、特殊かつ使いにくいインターフェース

4.2BSDプロセス間通信機能 一般的なインターフェースを意図

パイプ forkして分岐(親プロセスから派生)

分散UNIXシステム

サポートする機能

  • 透過性
  • 効率性
  • 互換性

UNIXが成功した最大の理由はモジュール性を提供したこと

通信ドメイン

  • 通信と名前管理のための標準的なセマンティクスを提供
  • TCPがデファクトスタンダードではなかったので、いろんなプロトコルがごちゃごちゃあった

ソケット

メッセージを送受するための抽象オブジェクト

  • 高信頼バイトストリーム(TCP)
  • 低信頼バイトストリーム(UDP)

  • 順序を保存するデータ伝送

  • 重複のないデータ伝送
  • 信頼性のあるデータ転送
  • 接続指向型の通信
  • メッセージ境界の保存
  • 帯域外メッセージのサポート

パイプ

データグラムソケット 信頼性を保証しない非接続型のパケット通信 ストリームソケット 信頼性のある、接続指向型のバイトストリーム通信

ソケットに対してつけられた名前をアドレスと呼ぶことにする

11.1.1 ソケットの利用

P478

  • アドレスファミリープロトコル
  • プロトコルファミリ
  • ソケットアドレス構造体

名前を割り当てる処理とソケットを生成する処理が分離

名前をつけずに使用される可能性 通信ドメインにとっては、ソケットに名前を割り当てる前に、システムに対して追加の非標準な情報を与えなければならない

ソケットアドレス構造体

P674

ソケットに対するアドレスを保持する汎用のこうぞお応対。connect()やbind()などの多くのプロセス間通信関数は、通信先の終端店のネットワークアドレスを認識し、それを示すソケットアドレス構造体をパラメータとして指定する必要がある

サーバプロセス

P666

プロセス間通信機能を介して、クライアントプロセスにサービスを提供するプロセス

http://linuxjm.sourceforge.jp/html/LDP_man-pages/man2/send.2.html

http://ja.wikipedia.org/wiki/%E7%9B%B4%E4%BA%A4%E6%80%A7_%28%E6%83%85%E5%A0%B1%E7%A7%91%E5%AD%A6%29

インターフェース

open read writeなどのシステムコールと直交するように設計されている

11.2 実装の構造と概要

11.2 実装の構造と概要

P481

プロセス間通信機能はネットワーク機能の最上位層に位置 アプリケーションからソケット層を通してネットワーク層へと流れ、逆方向にも流れる

ソケット層以下のネットワークサブシステム

ストリーム型ソケット

カーネルの中に関数がある

11.3 メモリ管理

プロセス間通信およびネットワーク・プロトコルが必要とするメモリ管理機構は、オペレーティング・システムの他の部分が要求するものと本質的に異なる

  • 多彩な大きさを持つメモリ領域
  • 可変長のデータ構造
  • 頻繁に発生するヘッダ除去作業

→特殊なメモリ管理機構

11.3.1 mbuf

メモリ管理機構はmbufと呼ばれるデータ構造を中心に構成

mbufの集合をチェーン チェーンの集合をキューと呼ぶことにする

利用目的を表すための型

型情報 チェーンが持つ付加情報 もしくは統計情報

パケットヘッダとEXTヘッダ

タグ 任意のメモリ領域を指す固定長の構造体 ネットワークサブシステムの中の異なるモジュールに関連する情報を管理するために利用

11.3.2 領域管理アルゴリズム

P486

割り当てコード CPU専用リスト