sw

void (*(*f[])())()の解読のしかた

C言語の演算子の優先順位はけっこう複雑な方だとおもう。

宣言の読み方が難しいのは宣言に出てくる演算子の優先度がわかりにくいのもあるが、ポインタのデリファレンス演算子 * が前置演算子になっているのが原因だとおもう。他の演算子 関数呼び出しの ()・配列アクセスの [] は後置演算子で、ポインタの * よりも優先度が高いのでポインタ演算子を先に効かせたい場合に括弧が必要になって見た目が複雑になる。

void (*(*f[])())() の読み方

f は変数
f[] fは配列
*f[] 配列の要素はポインタ
(*f[])() ポインタは関数を指している
*(*f[])() 関数はポインタを返す
(*(*f[])())() 返ってきたポインタは関数を指している
void (*(*f[])())() 関数の戻り値はvoid

仮にポインタデリファレンスが前置 の * ではなくて後置の @ だとしたらどうなるか。

void (*(*f[])())()

void f[]@()@()

と書けて、最初の型以外は左から右に直線的に読むだけで済む。

IMG_20180606_001314

いってきた: Gfarmシンポジウム2017

IMG_20171222_132058

司会 NPO 松山

[2017-12-22 13:31]

Gfarmファイルシステムの概要と最新機能 / 建部 修見(筑波大学)

  • 19000 downloads since 2007/03.
  • オーストラリアでもサポート(Libre solutions Pty Ltd; 主にdebian package担当)
  • HPCI共有ストレージ 大学間 〜100PB
  • release 2.7.8が最新
  • 書き込みキャッシュストレージ支援
    • クライアントとストレージのあいだにキャッシュをはさむ。
    • write back
    • キャッシュの仮想負荷よりもストレージの仮想負荷を上げてキャッシュに書き込まれるようにする。
  • データ移行支援
    • ストレージを書き込み禁止にできる。
    • 書き込み禁止だけどファイルの複製はつくれる。
  • Gfarm/バーストバッファ
    • 計算ノード上のNVMeを分散ファイルシステムにする。
    • 一時データ用
    • メタデータは永続化しない・冗長化しない (どうせジョブの動いているあいだだけでいいので)
    • 5400 iops (pgsql+journal+slaveMDS) -> 12000 iops(-slaveMDS) -> 15000iops (永続化なし)
  • ファイルシステム構築撤去の高速化
    • 構築0.31s 撤去0.19s
  • InfiniBand RDMA
    • 内部バッファをつかった転送とユーザバッファ(pin downed)に直接転送するのもできる。
    • max 1.8GB/s
    • max 1.2GB/s (POSIX API)
  • ディレクトリクォータ
    • ディレクトリ単位のファイル数・サイズの制限
    • XFSのとはちょっとちがう
    • パーティションにみせかけているので、ディレクトリ間のmv/linkはできない
  • 完全性
    • digestを書き込み・読み込みで計算してチェック。
    • 破損していたらlost+foundに移動。
    • 書き込み後6時間後に読んでチェッックしている。
    • 性能は -10%
    • 実際にIOエラーがないのにファイルが壊れたことがあった。
  • クラウドストレージとの連携も進行中

[2017-12-22 13:57]

大規模言語資源を活用した自然言語処理 / 井之上 直也、山口 健史(東北大学)

  • 乾研究室でgfarmをつかって研究している。
  • 言葉がわかるコンピュータ
  • メンバー 40名
  • 形態素解析、構文解析、述語構造解析・照応解析・省略語解析
  • 言葉がわかるとは? -> 行間を読むこと
    • 「庭に洗濯物を干したとたんに雨が振ってきた」
    • 目的・条件を知識からみちびいて、残念だったという推論ができる。
    • どうやって膨大な知識をあつめるか?
    • トレンド: webから知識をあつめてくる。
    • 言語構造解析による大規模知識獲得: パターン(フレーズ)とインスタンスのマトリクスから知識を抽出
    • 意見解析: 文章からトピック賛成・反対しているのかを推論する。うまくいかない例: 言論弾圧 vs 言論の自由を抑圧 表現がちがいすぎてうまくマッチングできない例
    • サイレントマジョリティの意見の予測: ソーシャルネットワークから意見を表明してない人の意見を推定する。
    • 論述問題の自動添削: 記述力を養うためには添削によるフィードバックが必須
  • うまく言語表現の多様性のせいでマッチングできない問題はdeep learningで解決する方向.
    • 例: the girl gasped -> she heard the news.
  • 典型的な処理
    • SNSデータ: JSON圧縮で14TB。これを基本的解析+フィルタ+頻度して実験データをつくるところまでgfarmで。そのあとはCPUサーバへ。
    • gfarm+GbEで構築。データの局所性が利用できるのがメリット。
    • 学生はまずpython。makeになじみがない。pwrakeをつかってもらうのはむつかしい。 -> シェルをたたいてがんばる。
    • gfwhereでデータがあるノードをさがしてsshで計算させる、というのがメイン。

[2017-12-22 14:21]

休憩

[2017-12-22 14:30]

HPCI共用ストレージ東拠点の機材更新に伴うデータ移行について / 中 誠一郎(東京大学)

  • 5年ぶりの機材更新: 西:理研(AICS) 東:東大 SINET5
  • 東大のスパコン室に空きがなく、新旧のストレージ機材の共存は不可
    • パイロットストレージのラックをつかってデータ移行
  • データ移行が終了->撤去->新規ストレージを設置 を順にくりかえしていく
  • データ移行方式
    • 複製数1のファイルが多数存在 平均1.3 (ユーザまかせにしたら、こうなってしまった)
    • moveではなくcopyで。 gfprep --mmオプション + 余剰レプリカを残す
    • replicainfo方式: COMPLEMENT_GROUP=移行元以外 こっちの方が速度が出た
  • まる1年かけて移行: 最初のころは並列度1で 17T/day。並列度あげて96TB/dayまででた。
    • gfprepはファイル数が増えると遅くなるっぽい。 -> 建部先生に相談して replicainfo に。
    • replicainfoで 3-15TB/dayしかでないレスポンスも悪化(gfarm 2.6.21)。 改良して 152TB/day (gfarm 2.6.23)
  • 移行ストレージはもったいないのでログインノードに転用予定。

[2017-12-22 14:50]

  • Q: サイレントデータコラプション対策した?
  • A: write verifyで確認している。

[2017-12-22 14:51]

[2017-12-22 14:52]

HPCI共用ストレージにおける階層型ストレージの導入構想 / 原田 浩(理化学研究所)

  • Gfarm日本征服計画
  • AICSも機材更新中
  • azureにアーカイブサービス実証実験中
  • RAID6(8D2P;100TB/disk) x 58set x11set
  • UNCAIによるクラウド基盤の提供
  • Gfarmの階層化支援機能
    • 余剰レプリカ自動削除機能をつかてキャッシュぽくする。
    • replica_check_remove_grace_used_space_ratio & replica_check_remove_grace_time
    • 二次ストレージへの一次書き込み抑制
      • 一次書き込み先選択アルゴリズム: busy hostには書かないようになっている
  • 手離れのいいGfarmサービス/Gfarmサーバのワンストップサービスが求めれれる。。。
  • 文科省から3年間はエビデンスを残すように指導がある -> スピードよりも容量がもとめられている -> クラウド
  • Azure(西日本リージョン)にgfarmスプールサーバをおいて実証実験中 (メターデータは東大)
    • azure VM -> client: 2Gbpsでている(たぶん帯域制限をくらっている)
    • 速度が出てないが調べてみたらおそいプロセッサがまざってるっぽい。
    • クラウドストレージはバイト単価も安くなってきたし、予算の年度区切り問題がなくなれば。

[2017-12-22 15:15]

[2017-12-22 15:17]

Gfarmを加速するDDN GfarmScaler / 橋爪 信明(DDN)

  • SFA4KXE,SFA7700XE: バックエンドはXFSで、Gfarmをコントローラ上でうごかす。
  • 14KXE/1VM: wriet 7GB/s read 8.5GB/s
  • pacemaker/corosync で XFSフェイルオーバー

[2017-12-22 15:30]

  • Q: 1MBからブロック変えたら?
  • A: 1MBより小さいとダイレクトIOがつかえなくて性能が落ちるはず。ブロックサイズはRAIDを組むときのchunksizeに関係。

[2017-12-22 15:32]

[2017-12-22 15:33]

ひまわりデータ解析を支えるPwrake/Gfarm / 村田 健史(NICT)

  • 気象災害は人口あたりでみるとアジアは多い。
  • http://himawari.asia
  • 公開されてないデータがあるのでは? -> データを1bitも隠さない・リアルタイム更新・だれでも見られるをポリシーに。
  • 日本なら10分以内に更新される。年間100万アクセスある。最大のユーザは気象庁?
  • ズームインしたときの画像は常につくりつづけている -> 3年間で73TB。ファイル数が多いのでinodeが足りなくなる。
  • 映像IoTがGfarmに期待すること
    • カメラをあらゆるところに設置する
    • raspinihaH264のエンコーダが載っていて高性能
    • ドライブレコーダのようにリアルダイム伝送できている
    • hpvt(high-performance vide transfer)映像伝送ツール
      • ACK 300msごとにネットワーク帯域を監視して、動的にエンコードパラメータを変えている。映像が途切れない。
    • raspiをつかっているのはOpenCVで画像処理できるため。
    • 2.5GB/day
    • 処理・保存でpwrake/gfarmの利用可能性
    • パッケージングして売れそうな予感

[2017-12-22 15:51]

  • Q: raspiはくるしくない?
  • A: FHD 30fpsはくるしい。730p 30fpsくらいならなんとか。
  • Q: ディレクトリ毎にメタデエータサーバを変えたら解決するのでは?
  • A: そんな金はないし、そこまでしてgfarmしてつかわなくても。。。

[2017-12-22 15:56]

休憩

IMG_20171222_160305

[2017-12-22 16:11]

パネル討論「ファイルシステムのこれから」

  • モデレータ: 建部 修見(筑波大学)
  • パネリスト:
    • 住元 真司(富士通) Post京
    • 井原 修一(DDN) Luster
    • 曽田 哲之(SRA) gfarm
    • 石橋 拓也(創夢) gfarm
    • 守分 淑子(数理技研) gfarm
守分
  • 数理技研の紹介
  • UNIXの移植
  • 1983年 socketがでてきた
  • 1993年 mosaicがでた
  • ファイルシステムをやるようになった
  • 2003年 gfarmの開発に関係するように
  • ディレクトリの名前管理は難しい。1ディレクトリに1万個もファイルつくられてこまる。(曽田さんコメント:Gfarmのディレクトリ構造は、オンメモリ・赤黒木なので、1万でも100万でも困りません)
  • readdirとファイル削除の競合は難しい問題 readdirのAPIが変えられないのがつらい
  • mmapは癌 マップされているとread/write権を剥奪できなくてつらい
  • 50年前のAPIをひきづっていて、変わらないのはいいけど、そろそろ変わってもいいのでは?
  • hard linkはなくてもいい。
  • ビッグデータで小さな大量のファイルのあつかいをなんとかしたい
石橋
  • 2002年 gfarm v1 の開発にかかわる
  • 当時はsyscallをフックしてたのをfuseをつかうように
  • もっとも大切なことは: 簡単に普通につかえること。普及していること。
  • 分散ファイルシステムはローカルディスクよりも速い!?
  • 無限のファイル数をあつかえるように。メタデータアクセスも分散させて。
  • ユーザ管理・アクセス制御・セキュリティを簡単に。
  • Gfarmの利点: POSIXインタフェースの妥協なき実装
曽田
  • 1996-2000 SCore
  • 2000/11- Gfarm v1
  • 2004-2007/3 Gfarm v2初期実装
  • (予算が...)
  • 2008/10- Gfarm
  • だいじなこと: 信頼性、性能、スケーラビリティ、拡張・移行が用意(リバランスが不要)
  • クラウドベンダーごとのストレージ、アプリケーションごとのストレージ、用途別のストレージが乱立しすぎ
  • 汎用の並列ファイルシステムに収束してもいいのでは メタデータ集中型・メタデータ分散型
  • 同期複製機能がほしい (現状はgfarmは非同期複製)
  • fine-grained lock (理研の64coreだと性能が出せてない)
  • メモリ外メタデータ (gfarmはメタデータがメモリに載っているのでスケールしなくなってる原因)
    • おもってたよりメモリが安くならず
  • リモートアクセスでの性能向上
    • 遠隔ファイルシステムとしては使われているほう
    • できる最適化ができてないものがある
  • 各クライアントでうごかすNFS gateway
井原
  • 2010年 DDN入社 (その前はSUN; OracleではHPCできないということで)
  • LustreとH/Wをインテグレーションして販売してた
  • 欲しい機能が実装されるのを待つのではなくDDN内でLustreの開発をするように
  • 開発メンバーは6人くらい
  • オープンソースの開発ではプライオリティづけがむつかしい
  • 欲しいデータに安全に確実にアクセスでいることが重要
  • Lustreをみているとかなり足りない機能がおおい (性能にふりすぎている)
住元
  • 1986-1997まではUNIXいじり 分散FTフィルシステムつくた(log based)
  • SCore
  • RCCS
  • PACS-CS
  • 京 MPI FS
  • ファイルシステムの現状と課題
    • VFSがでて作りやすくなったけどkernelオーバヘッドが
    • メモリ階層を考慮すべき
    • OSのプロセスだけでなく、仮想マシンとかコンテナとかLWKの考慮
    • Luster: posixセマンティック確保のほか、linuxオーバヘッド回避の話題がおおい
  • 用途別につかいわける時代になっている
  • ローカルは軽く・高速に
    • VFSじゃま: アプリケーション特化型・OSバイパス → ユーザレベルのファイルシステム
    • NVMeが持つ機能をもっとつかおう
  • ネットワークファイルシステムはユーザレベルでOSバイパス。
建部
  • POSIXやめましょう。
  • Q: (西) gfarmの普及を阻害している原因は?
  • A: むつかしそうだから? ユーザが構築できない。 CentOS/RHのバイナリ配布がないのが問題。 世界に配信すべき。
  • Q: (原田) gfarmの最大のライバルはクラウドストレージでは? ここ数年でAPIが高度化している。 scatter/gatherもできる。 データ移行もしやすく。 gfcopyを拡張して。
  • A: gfarmもMacからつかえるといいなぁ。 クラウドストレージはGとかAとか以外は共通APIがでてきてもいいなぁ。標準化活動が必要。

[2017-12-22 17:33]

P1160501xIMG_20171222_174505

いってきた: BitVisor Summit 6

京王線から南武線への乗り換えは久し振りだなぁ。余裕みすぎて9:15くらいに武蔵中原についた。

駅を出てぱっと目に入る富士通川崎工場の方にいってしまった。しまった。

imageimage

入口の守衛さんから事前登録しておいた名前でゲストカードをもらって入館。

imageimage

開錠はしっかり電源確保されていた。うれしい。ロビーに設置された無線LANは会場まで届かず残念。

[2017-12-05 09:59]

会場案内

[2017-12-05 10:02]

「BitVisorの現状と今後」 / 品川 高廣(東京大学)image

10:00-10:30(30分)
本発表では、最新のBitVisorに関する情報や、東京大学で運用しているvThriiの
運用状況についてお話します。
  • https://www.slideshare.net/shinagawa/20171204-bitvisor-summit-6-bitvisor
  • 今年も濃い話があつまった。
  • 未踏でbitvisorをやってる木村さんを招待講演
  • 発表者の層が拡がってきた
  • 参加登録者が増えてきた(初回なみ) connpassつかったためか新しい人が増えたっぽい
  • BitVisorとは: A Single-VM Lightweight Hypervisor
  • BitVisorは小さいのでセキュリティ的に有利 (KVMとかと比べて)
  • 準パススルー型 (一部だけフック(デバイスメディエータ)する以外はパススルー)
  • 2006年に開始、2009年にver1.0を公開。
  • BitVisor2.0の機能はもう榮樂さんしかわからない。。。
  • 東大での実運用 vThrii
    • 安定稼働している
    • MacのうえでMacOSとWindowsがうごいている
    • ローカルディスクの内容をアップデートしたい
    • ネットワークブートしつつ裏でHDDを更新できるので待たなくてもよい。
    • いちおう(ネットワークブートは重いので)夜間に月1で差分配信、4ヶ月に1回フル配信
    • 実はイメージをつくるのが大変。
    • イメージの切り戻し(rollback)はvThriiの標準機能
    • イメージをつくるときにIPをDHCPにするのを忘れて固定IPで配信してvThriiも使えなくなってインストールしなおし。
    • vThrii自体のアップデート macOSをアップデートしたらVT-d のアドレス変換のためで vThriiの対応が必要になった
    • パーティションサイズの変更
      • SSD 250GB くらいしかないのでソフトをインストールしてたら空きが足りなくなったので TMP領域を縮小した
    • vThriiは安定している
  • 品川研究室での活動
    • 査読つき論文2本
      • BMCArmor ベアメタルクラウドへの攻撃 不揮発性メモリを破壊/ウイルス感染される恐れ 不揮発性メモリの書き込みだけ準パススルーにすることで性能劣化を最小限におさえる。
      • Unified Hardware Abstraction Layer ... デバイスごとOSごとにデバイスドライバ書くのがたいへん virtioで統一したインタフェースを提供 Device Masqueradeで多様なデバイスに対応
    • VMMの若返り
      • VMMもメモリリークで性能が低下する(aging) -> とりあえずリブート
      • VMMを再起動しても上のVMは再起動したくない
      • TinyVisorでnested VMM。VMMを一時VMMにマイグレーションしてメインVMMを更新。
    • ベアメタルマイグレーション VMのマイグレーションはメモリ状態なのでマイグレーションは簡単 なんとかしてハードウェアの情報をマイグレーションする
  • BitVisor論文(VEE'09)のインパクト わりとインパクトがある google scalarで199件の参照数はなかなか
  • 今後の課題 無線LAN(メンドクサイ) ドキュメンテーション(榮樂さんがいろいろ書いてるのをまとめるとか)

[2017-12-05 10:33]

<招待講演> 「BitVisorをベースとしたカーネル解析プラットフォーム」 / 木村 廉(神戸大学)image

10:30-11:10(40分)
近年統合開発環境を始めとする多様なソフトウェア開発プラットフォームの登場
により、デバッグやテストといった作業は従来とは比較にならないほど高効率化
されている。しかし一方でデバイスドライバといったカーネルソフトウェア開発
においては、開発支援ツールが充実しておらず古典的なデバッグ手法を取らざる
得ないケースも多い。 そこでBiVisorをベースとしたカーネルトレーサー、デバッ
ガを提案する。 本システムではデバッグ対象のカーネルプログラムをBitVisor
上で動作させながらトレースし、それを元にデバッガで詳細な動きを追う事がで
きる。これによりカーネルソフトウェアのデバッグ効率を圧倒的に向上させ、早
期のバグ発見を支援する。 また既存のデバイスドライバの解析、脆弱性やバグ
の発見にも利用できる事を示す。

[2017-12-05 10:35]

  • Kernel Anylysis Platform based on Thin Hypervisor / @RKX1209
  • https://speakerdeck.com/rkx1209/kernel-analysis-platform-based-on-thin-hypervisor
  • 背景
    • Thin hypervisor ゲストシステムの監視を目的として軽量なhypervisor
      • sandobx, TCB削減, resource isolationの手間を省く.
    • カーネルの解析 静的なコード検証(linux driver verifier), エージェントをしこんでのIn-VMな動的解析, エミュレータやハイパーバイザーをつかったOut-of-VM
    • カーネルDBI (dynamic binary instrumentation for kernel)
      • 動的に検査コードをいれる メモリを監視したいならload/store命令の前後にコールバックをいれたり
      • 評価指標: performance concurrency reentrancy(監視コードがカーネルコードを使う場合) consistency(対象と解析データ整合性) availability(解析対象のバージョンに対する安定性)
    • drk いまのところいちばんよくできている In-kernel
  • kltracer: drkがkernel moduleだったのをVMM内にもってきて reentrancy向上 availability向上(複数linux version対応)
    • カーネルコードを実行するときだけ動的バイナリ変換(DBT)する
  • 設計/実装
    • システムコール(syscall/ssyenter) MSRかきかえてスタブにとばす
    • 割り込み IDTRをかきかえ
    • 例外処理 コールゲートをかきかえ
    • コードブロック(ベーシックブロック)をコピーして検査コードをついか
    • プラグインでコールバックを実装する(C++) 関連ライブラリはC++に移植した (実は未踏で時間があまったので。。)
      • static linkされる (ring -1でうごくダイナミックリンカはまだ存在しない。。)
      • Itanium ABIにしたがって実装 なぜかstd::mapをつかうとフリーズするバグが..
    • kltraceビルドシステム DBIエンジン・プラグイン・C++ライブラリ bareflankプロジェクトをベースに開発
  • 応用
    • timeless debugging すべての命令実行をトレースして記録 逆実行もできる qira(キーラ)がリファレンス実行
    • timeless debugging for kernel qemu -> kltracer lwipでリモートでみることもできる
  • 今後の課題
    • BitVisor for ARM? (組み込み業界向け)

[2017-12-05 11:06]

  • Q: MSR/IDTRにスタブをいれている理由は? exception bitを設定するとvmexitできて早くなるのでは?
  • A: それは知見ですね
  • Q: FJ: kltracerつかいたい
  • A: どこかのカンファレンスに出すタイミングで公開したい
  • Q: クローズドなソフトなデバッグに便利そう (ソースがあればKGDBでなんとかなりそうだし)
  • A: ですね
  • Q: nested VMでhypervisorのデバッグにつかえるか?
  • A: たぶん kltracer のフックにひっかからないけど、対応できるんじゃないかと
  • Q: ARM対応のモチベーションはどのくらい?
  • A: splatoonにあきたら。。。 今30%くらい

[2017-12-05 11:14]

[2017-12-05 11:16]

「BitVisor 2017年の主な変更点」 / 榮樂 英樹(株式会社イーゲル)image

11:10-11:40(30分)
2017年は、大規模PC環境向けOS配信管理ソリューションの開発に伴い、BitVisor
に含まれていた細かい問題が修正されています。その修正には、UEFI用ブートロー
ダーの改良、PCI configuration spaceアクセスの改良、一部環境で発生する問
題への対応などが含まれます。これらの変更内容について紹介します。
  • https://www.bitvisor.org/summit6/slides/bitvisor-summit-6-3-eiraku.pdf
  • ファームウェアドライバー切断機能 UEFIがデバイスをつかっていることがあるので一度来ってvirtioにきりかえ
  • UEFIブートローダ改良 パスワード認証 暗号化は未対応
  • PCI configuration spaceアクセス改良
  • Broadcom Thunderbolt Ethernet対応 macOSではPCIeブリッジのバスをいじっていた Windowsでは内蔵etherで対応済だった
  • デバッグ機能改良 dbgsh-uefi ieee1394logにリトライ機能追加
  • 一部環境での問題に対応 macOSでVT-dをつかっているのはどうやらアクセス制限するのにつかっているだけのようだ
  • バグ修正
  • コンパイル問題修正
  • 未解決問題
    • ACPIの解釈でいちぶ問題 ACPIを切ると回避できる

[2017-12-05 11:42]

  • Q: IOMMUをつかってbitvisorを保護するときに4GB以上のメモリをもっていると動かない
  • A: パッチ歓迎
  • Q: vThriiにも入る?
  • A: 基本的にはメンテコストをかけたくないので入るとおもう(というかすでに入っているとおもう) 一部のハック以外は。

[2017-12-05 11:46]

11:40-13:00 昼休み(80分)

駅ビルのマックで昼食。時間があまっていたのでQBハウス散髪。20分待ち。

image

「Implementation and Status of 'mruby in BitVisor'」 / 中田 裕貴(公立はこだて未来大学)image

13:00-13:30(30分)
現在のBitVisorでデバイスI/O監視などの機能を実装する場合,主にC言語でプロ
グラミングする必要があります.抽象度の高いオブジェクト指向スクリプト言語
をBitVisorの機能実装に使えるようすることを目指して,mrubyコンパイラと仮
想マシンをBitVisorへ組み込みました.本発表では,BitVisorへのmruby組み込
みの際に遭遇した課題とその解決法について紹介します.また,Rubyスクリプト
によるデバイスI/O監視の実装例を示し,BitVisorにおける Ruby言語仕様の有効
性について議論したいと思っています.

[2017-12-05 13:00]

中田さんはB2で授業を休めないため松原さん発表

@chikuwa_IT

  • https://speakerdeck.com/chikuwait/implementation-and-status-of-mruby-in-bitvisor
  • ハードウェアのプログラマグル化がすすんでいる SDN/ホワイトボックススイッチ/FPGAエクストリームコンピューティング
  • 組み込み用言語フレームワーク lua ELC micropython mrubyなど
  • なぜmrubyなのか? ruby大好きだから。
  • 技術的課題
    • libc, float, bitvisor API, mrib, mrbgem
  • libc
    • コンパイルしてみてないものを移植していく。(コンパクトなlibcをまるごと移植するのではなく)
    • mrb_allocate() BitVisor用意する
  • float
    • DISABLE_FLOATを指定しても完全には排除されず
    • とりあえず dummy のを用意 #define pow(x) (x)
    • やっぱりひどいので berkeley SofFloat をつかった
    • MRB_WIthout_FLOAT でできるようになった。
  • API
    • mrb_define_class_methodで呼べるようにラッピング
  • mirb
    • dbgsh経由でmirbにつながっている
  • mrbgem
    • 正規表現 mruby-pcre-regexp を移植
  • とりあえずうごいている。
  • mirbデモ
    • 出力はログにでるのがちょっと残念
  • TODO
    • 任意のmrubyのコードがBitVisorで動くのはいやなので、mruby VMを別プロセスにしたい。

[2017-12-05 13:21]

QA

[2017-12-05 13:24]

「BitVisorに「移植」する」 / 市川 遼(東京農工大学)image

13:30-14:00(30分)
BitVisorにLuaの処理系を移植し,LuaからBitVisorの機能を呼び出せるようにす
ることでそのインターフェースを提供する仕組み「LVisor」を提案した.その際,
libcだけでなくGLibなど外部のライブラリを移植する必要が生じ,大量に修正作
業が発生した.本発表ではLVisorの実装方法を通じて,BitVisorに新しくプログ
ラムを移植する汎用的な方法について説明する.

[2017-12-05 13:26]

@icchyr

  • LVisorの背景
    • 複雑な記述ができる
    • evalで動的にプログラムを追加
    • VMMに動的機能追加
    • VMI(Virtual Machine Introspection)があるとうれしい
  • Luaの特徴
    • 依存ライブラリがすくないとか
  • Luaはプロトタイプベースなので動的にメソッド追加
  • 実装方針 できるだけ Ring 0 ではうごかさないようにする。Luaを移植してからLibVMIを移植。
  • Luaのビルドシステムは単純なので移植がらく
  • 既存のlibc musl libcを移植した (eglibc, uClibc, newlib, musl libc)
    • stdout: __fwritex()をputcharで実装
    • stdin: 対応せず
  • LibVMIの移植
    • Glib,json-cにも依存
    • Xenをベースにdriverを実装
    • jsonが3MBと大きいのでtextに埋め込む方法はなんとかしたい(ファイルシステムがあつかえないので)
  • デモ

image

[2017-12-05 13:54]

  • Q: LibVMIをつかうのが目的だがLuaはなぜ必要なのか?
  • A: Luaをつかうことで複雑なことが書けるようになる
  • Q: BitVisorでつかう目的は?
  • A: パフォーマンスと現場で利用するには便利
  • Q: /tmpの例は timeobject timeuse問題があるのでは?
  • A: おっしゃるとおり
  • Q: Luaの新バージョンに追従するコストは?
  • A: musl libcでの対処がほとんどなので lua の改造コストはbitvisorのAPIをたたくところだけで少ない。
  • Q: libcを公開してくれるとうれしいけど、そうなるとBitVisorがOS化してしまうジレンマ

[2017-12-05 14:00]

「BPFを利用したBitVisor内部でのパケットフィルタリング」 / 味曽野 雅史(東京大学)image

14:00-14:20(20分)
ハイパーバイザ内でパケットフィルタリングを実行することで,ゲストOSによら
ない,強制的なフィルタリング可能になります.動的な設定変更が可能でかつ軽
量・安全なフィルタリングを実現するために今回BitVisorとBerkeley Packet
Filter (BPF) を組み合わせたフィルタリングシステムを作成しました.本発表
では,その技術詳細と応用例に関してお話しします.

[2017-12-05 14:01]

  • https://speakerdeck.com/mmisono/bpfwoli-yong-sitabitvisornei-bu-defalsepaketutohuirutaringu-plus-a
  • intermediate bufferをつネットワークAPIがある
  • BitVisorがshadow descriptorとshadow bufferをもっているのでpass moduleでフィルタしたらよい
  • BPFをつかう理由: 効率 JIT 十分な記述力 負方向のジャンプがない 検証が容易
  • classic BPF(cBPF; libpcap), extended BPF(eBPF; linuxでつかわれている; clang)
    • eBPFだとCで書ける
  • BPFプログラムの設定方法: VMcall, lwIP.
  • 1GbE
    • thruputは差が出ず
    • ping RTTはbaremetalとippassで差はあるがフィルタかけても悪化はしない。
  • eBPF Tracing in BitVisor
    • VMexit reasonの統計をとったりMMIOのアドレスの統計をとったり
  • デモ

image

[2017-12-05 14:20]

  • Q: 利用予定は? eBPFのコードをring -1になげこめるのは問題になるとおもう。jit spray
  • A: 利用予定はない。 検証はやろうとおもえばできる。
  • Q: 外部の関数を呼べるようになったらBPFはLua/mrubyになっちゃう?
  • A: 安全な外部関数しかよべないようにするのがふつう。
  • Q: VMexitでとれる情報は?
  • A: BitVisorからBPFに渡す引数しだい(基本的にはBPFでは引数しかみられない)

[2017-12-05 14:26]

14:20-14:40 休憩(20分)

「大学の教育研究用端末上でのベアメタルハイパバイザの運用」 / 大山 恵弘(筑波大学)image

14:40-15:10(30分)
筑波大学が全学の教育研究用に提供している計算機システム(全学計算機システ
ム)では,学内の16拠点に配置された1000台以上の端末でBitVisorベースのベア
メタルハイパバイザであるvThriiが稼働している.本発表では全学計算機システ
ムの概要,および,全学計算機システムの導入や運用で得られた経験について述
べる.

[2017-12-05 14:45]

  • https://www.bitvisor.org/summit6/slides/bitvisor-summit-6-7-oyama.pdf
  • 全学計算機システム 筑波大学全学の教育等(not 研究)のために提供されるシステム
  • 1000台以上の端末でvThriiが動いている
  • 筑波大学には31サテライトもある
  • OSのデュアルブート Win 10 Enterprise or Ubuntu
  • vThriiの採用動機
    • winとlinuxのデュアルブート・価格もそこそこ・性能もそこそこ・東大で実績
    • ネガティブな理由もない
  • 学園祭の広告に vThrii がでてた。だれ向け?
  • windowsは電源をいれて90秒でワードが起動する。linuxは60秒。初回ログインは10分たってもログインできないということも。
  • ユーザのプロファイル情報をとってくるのに時間がかかっている
  • 起動できなかったりフリーズしたらvProで再起動。だめならケーブルチェック。それでもだめならハード故障としてエスカレーション。
  • vThriiがはいることで障害の原因候補が1つふえるが、一般ユーザはWindowsを疑う(vThiiの知名度のひくさと存在感のなさ)。
  • 性能・互換性は導入前に評価した
    • ubuntuでUnixBench -> vThriiのオーバヘッドは0.1GHzくらいの差でしかない
    • Paranoid fish (Pafish)などでVM検出をこころみたが、ほとんどで実機と判定された。

[2017-12-05 15:11]

  • Q: (情報系の人は実は教育計算機はつかわないのですが)virtioはつかってない?
  • A: virtioになってる (NICは2このってるけど1つはvPro用になっている)
  • Q: 障害の統計(障害理由とか)はとっているか? 他大学での更改での参考になる。
  • A: とってない。スタッフの間では暗黙知がたまっているとおもうので報告したい。
  • Q: (ユーザは1,2年の共用課程)BitVisorならではの機能はあるか?
  • A: hypervisorがあることでのメリットがあるといいかも。一時的に実験用のOSを配るとか、いいかもしれない。
  • Q: 24時間稼働のところでwindows updateはどうなる? アンチウィルスは?
  • A: 端末ではwindows updateがうごかないようにして、vThriiでイメージを配布している。 アンチウィルスも週1でしか更新してないのでログインすると警告がでる。。。
  • Q: イメージは1種類?
  • A: 1種類。配信サーバは複数用意している。正確には図書館用のイメージが別途あったりする。long terml service branch(LTSB)をつかっているのでedgeはつかえない。
  • vThriiが起動しなかったときは都度イーゲル社に報告しているが、原因判明にはいたらず。

[2017-12-05 15:24]

[2017-12-05 15:26]

「Unsafe Nested Virtualization on Intel CPU」 / 深井貴明(筑波大学)image

15:10-15:40(30分)
Unsafe Nested Virtualization は,仮想化支援機能を用いる VMM をBitVisor
上で動作させる機能です.通常の Nested Virtualization と異なり,ゲスト
VMM に悪意がないことを前提に様々なエミュレーション処理を省き,比較的シン
プルな実装になっています.この機能はこれまで AMD CPU にのみ対応していま
したが,現在 Intel CPU への対応を進めています.発表では,Intel 対応にお
ける実装の詳細,現在の対応状況,および簡単な性能評価の結果について説明し
ます.
  • https://www.slideshare.net/DeepTokikane/unsafe-nested-virtualization-on-intel-cpu-83409391
  • L2 VM / L1 VMM / L0 VMM
    • L1にfull emulationのをもってくれば動くのはあたりまえ。仮想化支援で速度向上したい。
  • L2->L1にvmentryしたいときでもL0を経由している。
  • L1を信用してL0ではアドレス変換しない。
  • BitVisorはnon GPU(BSDライセンス)なはじめてのnested VMM。 bhyveはBSDライセンスだがnestedがうごかない。
  • 榮樂さんがAMD版(AMD-V)のnested VMMをつくったが、手間がかかるIntel版(VT-x)はあとまわしになっていた。
  • intel版はVMX命令が多い。
  • vCPUのマイグレーション 物理コアでキャッシュしているVMCSをVMCLEARしてメモリに吐かないといけない。

[2017-12-05 15:49]

  • Q: VMCSはふつうのキャッシュ?
  • A: VMCS専用のキャッシュ
  • BitVisor Advent Calendar 2017 がBitVisorのドキュメントになるので、みんな埋めてほしい。
  • ぎりぎりまで空けとくと、神が降臨して知らなかった情報が書き込まれるという。。。
  • VMCS shadowingはVMREAD/VMWRITEの肩代わりをしてくれるものらしい。

[2017-12-05 16:00]

「Introducing NVMe driver for BitVisor」 / Ake Koomsin(IGEL Co.,Ltd)image

15:40-16:00(20分)
In this presentation, we will talk about an overview of NVMe driver
implementation for BitVisor.

[2017-12-05 16:02]

(in English)(英語ききとり能力ゼロのため、発表はさっぱりわからずorz)

  • https://www.bitvisor.org/summit6/slides/bitvisor-summit-6-9-ake.pdf
  • admin queues と I/O queues がある。それぞれに submission queueとcompletion queueがある。
  • submissonQのtailに書いたらdoorbellたたいて、コントローラがheadから処理してcompletionQに書いて割り込みいれてホストが処理したらdoorbellたたいてhead更新、というながれっぽい。

[2017-12-05 16:19]

(QA in English...)

[2017-12-05 16:23]

ライトニングトーク(LT) 16:00-17:30

「自作OSもくもく会の紹介」 / cybozu 内田 image

[2017-12-05 16:28]

@uchan_nos

  • 低レイヤーの勉強会
  • もくもくとコード書くとか本を読むとか、相談したり

[2017-12-05 16:31]

[2017-12-05 16:32]

学会のの宣伝 / 産総研 秋山 image

  • Euro Sys
  • non-volatile memory

[2017-12-05 16:33]

[2017-12-05 16:35]

nested vm デモ / 深井

BIOSのプライマリを外部画面にしておくとgrabの画面が出せるらしい

bitvisor上でKVMがうごく

bitvisor上でVMware playerがうごく

[2017-12-05 16:42]

  • Q: 出荷しないならL0 VMMがBSDライセンスにこだわらなくてもよいのでは?
  • A: 神経質になるならクリーンルーム開発でGPLのコードを参照できないので、あった方がよい。

デモ

  • L0のBitVisorがうごいているのを確かめる方法がない。
  • dbgshはL1のがうごいているはず。
  • VMM 3段はむりだった。

フリーディスカッション

[2017-12-05 16:53]

自己紹介タイム

[2017-12-05 17:20]

クロージング

[2017-12-05 17:22]

懇親会@木村屋本店 武蔵中原

imageimageimageimage

終了タイムは23:00ということだったが終電が気になるので22時くらいに先に抜けてきた。

P1160348x

いってきた:ChainerMNによる機械学習の高速化勉強会

image

上野での移動に時間がかかってしまったのと、ゲートシティの地下1階で会場の入口がなかなかわからなかったのとで、4分遅刻した。小さな会議室が開場だったので受付で座席指定されて前から詰めていくスタイル。

image

[2017-11-28 18:34]

分散深層学習とChainerMNについて / PFN 鈴木脩司

  • 資料
  • PFN: 交通・製造業・バイオヘルスケアをやっている
  • data parallel vs model parallel
    • model parallelは並列化効率がよくない。GPUのメモリがすくないときにつかわれた。
  • sync vs async in data parallel
    • 非同期型はパラメータサーバの更新はワーカが同期をとらずに更新
  • 「distributed deep learning」で検索するとasyncがでてくる。
    • スループットをみるのは愚か!
    • gradient staleness のせいで学習精度があがらない。
    • stale gradients: 古い勾配
    • いまどきはsyncをつかっているチームがおおい。
    • 非同期型でもうまくチューニングすればいけるんじゃね?(予想)
    • 同期型のほうがチューニングしやすいのはたしか。
  • ChainerMNはMPI(SPMD: single program multi data)で動作。
  • AllReduceで全勾配の平均をくばる
    • forward-backward-optimize が
    • forward-backward-allreduce-optimize になる
    • 1024ノードでもスケール(weak scaling(台数ふやしたら問題も大きくしないと効率が落ちる))している
  • アプリを変えないといけないとろ
    • communicatorの作成 (allreduce用;ネットワークにあわせて選ぶ必要がある)
    • GPUの指定 (rank番号(comm.intra_rank)からGPU番号を生成するのが簡単)
    • マルチノード用のoptimizer optimizer_Adam()
    • データの分配 scatter_dataset() をつかう。
    • マルチノード用のEvaluatorの作成 create-multi_node_evaluator(evaluator, comm)
  • FAQ
    • Q: chainerMNをつかったら遅くなった
    • A: 通信を速くしてください
    • Q: MNISTが速くならない
    • A: データサイズが小さいので速くならない (MNISTは動作確認用)
  • 高速化: プロファイリング、バッチサイズをあげる、communicatorをえらぶ
  • アムダールの法則を理解しよう。 allreduceは逐次処理になっている。
  • プロファイラ: cProfile, NVPROF
  • cProfile:
    • import cProfile
    • import pstats
    • pr = cProfile.Profile()
    • pr.enable()
    • ...
    • pr.disable()
    • stats = pstats.Stats(pr)
  • NVPROF
    • mpiexec -n 2 nvprof -o '%h-%p.nvprof' python ...
    • NVPPP(nvidia-visual-profile)でみるのがおすすめ (データサイズがおおきくなるのでイテレーションを少なくする、設定ファイルで大きなファイルを読めるようにするなど)
  • バッチサイズを上げる -> AllReduceの時間が相対的に小さくなって並列化効率があがる(精度が落ちてないか注意) 学習率をいじるとか。
    • 学習率のliner scaling rule: バッチサイズをk倍にしたら学習率もk倍にする
    • gradual warmup: イテレーションごとに5 epochのところでk倍にする。
    • decaying learning rateの変わりにバッチサイズを大きくする
  • コミュニケータは PureNcclCommunicator がおすすめ(2017年11月現在)l
    • NCCLがネットワーク構成を自動判定してくれる
  • allreduceをfloat16にしてからやると通信量が(100MB->50MB)減って時間短縮。ほぼ精度に影響なし。
  • ChanerMNの今後
    • モデル並列をつかえるように
    • double bufferingでallreduceの時間を隠す
    • fault-tolerance
    • float16

[2017-11-28 19:24]

  • Q: ネットワークがIBじゃなくて10GbEだとどうなる?
  • A: 1GbEはやったことがあるが、ひどかった。allreduceおそすぎ。BWかlatencyかはモデルによる。

[2017-11-28 19:29]

[2017-11-28 19:31]

さくらインターネット高火力コンピューティング基盤でChainerMNを試す / fixstars 吉藤尚生

  • 資料
  • 結果: さくら高火力でうごかしたがChainerMNをつかっても速くならなかった。
  • {フレームワーク}×{クラウド} いろいろある
  • さくらは時間課金なのがうれしい。あとマシン貸しなのでつかいやすい。あと日本語ヘルプがある。
  • 性能が出ない理由はallreduceがおそかった。10GbEなのに0.04Gb/sしか出てなかった。(さくらに問い合わせたが回答なし)
    • 月課金ではなく時間課金だから遅いのかは分からず。月課金だとethernetではなくinfinibandにすることもできるらしい。
  • 学習データのダウンロード中も課金されるのがツラい。

[2017-11-28 20:11]

懇親会

imageimage

[2017-11-30 21:30]

NCCLはナックルなんだろうかニッケルなんだろうか。NVIDIA Collective Communication Libraryだからエヌックルあたりが無難そうな気がするが。

image

いってきた: Mesos Meetup Tokyo #3

IMG_20171101_184221

[2017-11-01 19:01]

オープミング

  • #MUGT
  • もくもく会みたいなのもやりたいなぁ。
  • Mesos User Groups は25都市が登録。
  • さいしょはデータ解析でつかわれて、コンテナでつかわれるようになった、まだtensorflowなどでつかわれるように。
  • Kubernetes
  • distributed tensorflow support

Mesosを使用した分析サービス「e19(千京;せんけい)」の紹介と開発の話 / 木内満歳(きうち みつとし)

  • e19: 自然対数のe。10^19の意味だったが。データサイエンティストのためのサービス。 https://e19.io
  • 開発のなりゆき
    • SI企業のなやみ: 案件ごとにエンジニアをわりあてるが、エンジニアの数で売上がきまってしまう。案件ごとに難易度がちがう。エンジニアごとにスキルもちがう。
    • プロダクトをつくって売ればエンジニアもお客もハッピーなのでは?
    • 世の中にはデータ分析サービスはくさるほどあるが、過去の成功と遺産にとわられているのでは? Hadoopの膨大なスタックにはまってる。ちょっとパラメータをいじっただけでバランスがくずれてつかいにくという苦情。
    • 技術とニーズがずれはじめてるかも?
    • Hadoop スタックから Spark ひとつでシンプルに。BIはapache drillつかったりするけど。
  • なぜmesos?
    • Sparkでつかえるクラスタ管理ソフト(Mesos,YARN,Standaalone)のひとつだったから。YARNはむつかしい、standaloneは簡単だけどマルチユーザに対応してない、他のサービスを同一フレームワークであつかえない。
    • Agentは複数だが、1ZK 1Master の構成。
    • e19ではクラスタを単一ホストっぽく見せる(シングルビュー)ようにしている。データサイエンティストの方々はクラスタに詳しくないため(sshシラネ、クラサバしらね)。バッチスケジューラ(Retz, Aurora)も入れてない。
    • Q: DC/OSじゃないの?
    • A: つかいたかったけどまだOSSになってなかった。
    • データサイエンティストは分析用ライブラリにはこだわりがある。(xgboost,statsmodels,causalimpact,Bokeh,NLTK)。pip でインストールできるようにしたい。
  • 開発体制・使用ツール (オフレコ)
    • ぶっちゃけ2名
    • UI=bootstrap
    • アプリフレームワーク=Meteor。javascript。python:jangoをリッチにしたかんじ。
    • インフラ=Ansible。難しいことをやるには面倒。chefにしたい。
    • DB=MoboDB。Meteor指定。
  • 開発方針: 無駄にがんばらない (兼業なので)
    • syslogない。systemdでstdoutをジャーナルに書く。
    • 環境: Fedora,Mac,CentOSでもうごいている。
    • 管理はJIRA, Confluenseで。
  • どうなった?
    • ジレンマは解決されなかったが、
    • 自分達で売るものができたのはよかった。
    • 使いたい人よりも売りたい人のほうが多かった。なぜかわからんが。
    • チャンネル登録よろ
  • 今後の予定
    • 売りたい人のためにマイクロサービス・可搬性向上(プラットフォーム非依存)させようとしている。
    • http://www.creationline.com

[2017-11-01 19:45]

crashacademy で過去の動画がみられるらしい。今回も録画しているのでそのうちみえるようになるはず。

[2017-11-01 19:46]

たいそうりっぱになったねえ。 DC/OS 1.10 / @jyoshise

  • https://hackmd.io/p/SyHr9e1CZ
  • 9月に出た
  • 事前アンケートではMesos,DC/OSにさわったことがない人が多いのでデモ
  • DC/OS Universe Packageのしくみ
    • 設定用のjsonファイルをかくだけ
  • https://dcos.io, https://github.com/dcos https://dcos.io/docs
  • Mesosのディストリビューション的なもの エンタプライズ版もある
  • Spartan: MesosのDNS。.localだけじゃなくドメインをつかえるようになった。
  • CNI(cloud native interface)対応
  • Universal Container Runtime (UCR) つかうように。dockerはずし現象?
  • kubernetesをDC/OSでうごかすメリット: かんたんにデプロイできる。DC/OS上のデータサービスとの接続が簡単。共通リソースの管理。
  • Marathonじゃないのは? 長いものには巻かれろ?
  • 鉄板データサービズ(M7): Mesosphereがpackageメンテナンス。production ready。
  • nodeの数やgpuの数を指定するだけでてきとうにわりふってくれる。
  • DC/OSはVagrantで1ノードでうごくが、いろいろやるなら最低5ノード。
  • DC/OSのコミュニティはMesosよりも活発。
  • CNCFへのあゆみより。パーシステンスストレージとか。

[2017-11-01 20:11]

休憩

[2017-11-01 20:22]

Serverless w/Mesos / @kojiha_

  • デモしようとしたらバージョン不整合でうごかないのでトラブルシューティング中...
  • Mesosでつかえるserverlessツール: Gestalt, Fancatron, iron.io
  • iron.io: フロントエンドだけクラウドに置いて実行はオンプレミスで、ということもできる。

[2017-11-01 20:36]

[2017-11-01 20:39]

すべてのWaitingを生まれる前に消し去りたい / @kotatsu360

  • https://speakerdeck.com/kotatsu360/goodby-waiting-status-forever
  • VASILY: DC/OSはつかわず。Marathonでdockerコンテナをうごかしている。
  • Marathonの"Wating"を解消したい
    • リソースがいつまでたっても確保できない問題
    • いったいなんのリソースが不足しているのか分からない。
  • 1: リソース不足
  • 2: タスクの制約(Constraints. GPU必要とか1ノード1タスク(hostname:UNIQUE制約)とか)
  • 3: リソースの利用許可がない (ポート80をつかいたい(requirePorts)がagentにresourcesオプションを追加してなかった、など)
    • upgradeStrategyでminimumHealthCapacityとmaximumOverCapacityを0にすると(新規タスクのデプロイ前に既存タスクをkill) 瞬断が許される場合につかえる

[2017-11-01 20:58]

@kotatsu360さんにリソース不足になったのを自動的に検出する方法はあるかきいてみたところ

  • Web UIからはわからない
  • marathonとmasterのAPIから必要リソースと手持ちリソースがわかるのでAWSならLambdaで監視できる

とのこと。

IMG_20171101_201352

記事検索
月別アーカイブ
アクセスカウンター

    タグ絞り込み検索
    ギャラリー
    • 今日の練習 2018-11-13
    • 今日の練習 2018-11-11
    • 今日の練習 2018-11-11
    • 今日の練習 2018-11-10
    • 今日の練習 2018-11-10
    • 今日の練習 2018-11-10
    Amazon
    楽天市場
    adby google
    LINE読者登録QRコード
    LINE読者登録QRコード
    • ライブドアブログ