iijlab

IIJLabセミナー: 不揮発性メモリ時代のネットワークスタックおよび ACM HotNets 2016 参加報告

image

[2016-12-26 17:59]

講師 本多倫夫氏 登場

[2016-12-26 18:03]P1120351x

PASTE: Network Stacks Must Integrate with NMVM Abstructions

  • NVMMs: non-volatile main memories
  • persistent
  • byte-addressable
  • low latency: 10s-1000s o ns (お値段による)
  • ファイル名が永続化するためのしくみ、とも考えられる。
  • direct mmap()-ed files
  • data structureが変ったらネットワークスタックはどう変るか?
  • case study: WAL(write ahead logging)
    • B-tree(メタデータ)のアップデートは時間がかかるので一旦logに書いてclientにackを返す。
    • データの流れ: client -> server: nic->dram->networkstack->(read)->app->(write/fsync,memcpy/msync)->storagestack->storage->..
    • 実験:
      • NVMe: 2000us。ネットワークはやれることはない。ストレージで律速。
      • NVMM: 42usくらいでおわる。ネットワークでやれることがある。
    • 実際には並列アクセスされるのでNVMMをつかっても(ネットワークだけストレージなしの時よりも)スループット/レイテンシは落ちる。
    • NVMMつかっても、まだまだ永続化するコストがある → メモリコピーによるキャッシュミス
      • rx_buf→app_bufのコピーはapp_bufが固定なので(キャッシュヒットして)コストは安い。
      • app_buf→log_file(NVMM)は毎回違う場所になるのでキャッシュミスしてコスト高い。
      • DDIOがあるのでNIC受信はLLC(last level cache)にいきなりヒットするのでキャッシュミスがすくない。
      • kernel内のmemcpyはユーザ空間のmemcpyに比べて最適化されてない?のでキャッシュミスが多くなる。
    • 受信バッファ(in kernel)をNVMMに置けば解決。/mnt/nvmm/pktbufs とか。ログは /mnt/nvmm/appmd (アプリメタデータ) に。
  • FAST Logging with PASTEP1120352x
    • NICがrecvした段階ではLLCに乗っているだけでflush(clflush)してはじめて永続化する。
    • clflushはキャッシュライン単位でフラッシュする。msyncはページ単位。
    • データはNVMMのポインタをコピーすることでmemcpy回避(コピーするのはメタデータだけにする)。
    • netmapを改造して実装。 pkg-gen -i eth1@/mnt/pmem/bufs -f rx
    • tcp/ipはstackmapをつかっている(先行研究)。
    • ざっくり thruput 10%up, latency 40%up した。
  • 関連研究:
    • NVMM関係ないネットワークスタック(高速ネットワーク)
    • NVMMつかったファイルシステム(高速ファイルシステム)
    • NVMMだけどRDMAつかってネットワークスタック関係ない(HPC系)
  • まとめ:
    • RDMAはどこでもつかえるわけじゃない!
    • 単体で改善するだけでは十分じゃない!

[2016-12-26 18:31]

  • Q: clflushをlazyにできるときもあるとおもうが
  • A: writeのlatencyが長いNVMM(3dxpointとか)もあるので、アプリがLLCをflushするかどうか決めるようにしている。トランザクションの永続化要求はアプリによってちがう。multi-coreのときにスケールしないかもしれないのはfuture work.
  • Q: いま売られているものと今後でてくるものはちがってくるとおもうが、どうなる?
  • A: いま売られているのはbattery-backupedで速いやつなので、3dxpointみたいな遅めのやつでは.. 研究者はfpgaでemulatorかdramで実験している。
  • Q: フラグメントしない?
  • A: ほんとうに保存(リングバッファから別の領域に?)しおわってはじめて回収できるようになる。netmapでdouble bufferingがあるので穴あきもんだいはok。

[2016-12-26 18:39]

Report on ACM HotNets 2016 P1120353x

  • 90人くらいなので学内ワークショップなフレンドリーな雰囲気。
  • frontier network: 辺境の地でのネットワーク
  • MPTCPでマルチホームのときに他のISPにトラフィックをおしつけたり
  • RDMAが流行り
  • datacenterでマルチリンクのときにトポロジをどうするとか
  • RDMAでpriority-basedだとデッドロックしちゃうのでどうしようとか

[2016-12-26 18:48]

  • Q: もりあがってた話題は?
  • A: 発表時間がかぎられているので、どの話題もそれほどもりあがらない。
  • Q: 気になったのは?
  • A: internet blockchain(BGP,DNSをやめようというやつ)がおもしろかった。
  • Q: MPTCP ホットポテト問題? (ホットポテトってこれか?)
  • A: ISP間の公平性の問題提起。appleがECNでREDやってるけどISPでもやるの?とか。

[2016-12-26 18:52]

  • Q: ネットワークスタックをどうかえたい? pullupじゃなくて、とか。
  • A: netmapはlinuxには絶対入らないし、freebsdにはNVMMがないし、アプリ専用のスタックをつくるのは懐疑的(カーネル内のプロトコルスタックは複雑なので触りたくない)。
    • FreeBSD: RAMとして見えるけどpageをどうみせるとかグルーの部分がぜんぜんない。そもそも人がいない...
  • Q: RDMAきらい?
  • A: LLCにRDMAする話はきかないし、あまり議論するつもりがない。(ちなみに会議にはHPC屋はいなかった)
  • Q: DDIOは3種類: 1:ringbufだけ、2:メタデータも、3:ペイロードも。
  • A: ペイロードありで実験している。

[2016-12-26 18:59]

飯田橋駅工事中で、西口に活気がない感じがした。

P1120355x

IIJlabセミナー: Linux Kernel Library: 再利用可能なモノリシックカーネル

image

  • 動機
    • ネットワークシミュレータの研究をしていて、シミュレーションと実機とで二重にコードを持ちたくなかった。
    • Linuxのネットワークコードは618KLoCもある。
    • だからといってシミュレーションするときにLinuxをVMで動かすと遅い。
    • 新しいソフトを使うときにVMで検証してる?
      • マイクロソフトでさえ頻繁に検証するわけではない実態。
    • (一般的にいって)性能と利便性のトレードオフがある。
    • 問題はindirectで解決できるという名言。
  • AnyKernel (NetBSDというOSのrump kernelみたいなもの)
    • clock,memory,scheduler,deviceIO(NIC,blockdev)だけがarchitecture dependで
    • その上にarch independentな層、さらにその上に(改造なしの)カーネルをもってくる。
    • カーネルの上にAPIを被せてアプリケーションはAPI経由でカーネルを利用する。
  • やりかた
    • Arch independentな層を入れたり
    • 抽象的なCPU archを導入したり
  • アプローチ
    • フルスクラッチ: mirage, includeos, seaster, mtcp
      • 性能的に有利
    • 移植: OSv, libuinet, sandstorm
      • 最新版への追従性に難
    • anykernel(移植ではなくそのままもってくる): NetBSD rump, UML, DrawBridge(マイクロソフト製,論文からするとおそらく)
      • カーネル資産をつかえる、最新版への追従性も良好
  • LKL: Linux Kernel Library
    • https://github.com/lkl/linux
    • カーネルのライブラリ化
    • 2007年にルーマニアでスタート(rumpと同時期)
    • IOはいまどきのvertio
    • win32,linux,freebsdなどの上で動作
  • DCE/LibOS
    • 2008年スタート
  • LKL vs LibOS
    • LKLはpthreadでIRQ,kthread,timerを実装
    • LibOSは高位APIをpthreadで実装
  • デバイスイタンフェース: TAP, DPDK, VDE
  • wrapperの規模は2400LoC、CPU非依存
  • ホストOSにはNT,POSIX,MacOS,Linuxがつかえる。
  • LKL APIの種類:
    • (1) LKL syscall: ふつうのsyscallに相当: lkl_sys_hogehoge()
    • (2) Hijack Lib: LD_PRELOADでsocket()をlkl_sys_socket()に曲げたり. linux以外ではsyscall emulatorが必要になる
    • (3) extended(alternative)libc: musl(マスル)。 libcを拡張してアプリに機能を提供。
  • アプリケーションの例
    • ns-3(ネットワークシミュレータ)
      • ns-3の中でLKLを読み込んでネットワークスタックを利用する。dlmopen
      • 実機とちがってタイミングが毎度同じなので再現率100% (仮想クロック使用時)
      • valgrindでデバッグできる。
    • 簡易カーネルバイパス
      • LD_PRELOAD=hogehoge-tcp.so firefox などとして、ホストカーネルとは異なるネットワークスタックをつかってみたり。
    • ext4読み書き
      • windows上でext4のディスクにアクセスする。
    • unikernel
      • 単一アプリにカーネルをリンクする、小さなゲストOS。rumpに似ている。
      • たとえばping6コマンドにLinuxを埋め込むなど。
      • たとえばarm-qemu上でゲストOSを起動しないでpingを実行するとか。(pingにOSがリンクされている)
      • 今日の発表もこれをつかっているらしい。
  • 性能について (UDP 1000B)
    • native kernelがRTT/thruputともにベスト
    • DPDKはRTTがとんでもなく遅い。thruputも低い。
    • netmapとtapはthruputが低い
  • Q:コストは?
  • A: 初期化はふつうのカーネルよりも速い。デバイスの応答を待つ必要がないのと、不要なデバイス初期化をなくせるのとで。メモリフットプリントはとても大きい。おそらく実装の問題。らくらくGB越え。qemuでメモリサイズをGBにしないと動かない。
  • Q: 改造量は?
  • A: IRQ,threadなどだけをposixで実装して、他の下廻りはカーネルのコードをそのままつかっている。
  • Q: 昔のSunのマシンがやっていたメモリリフレッシュとかはどうなるだろう?
  • A: たぶんそのまま動く???
  • Q: ns-3での再現性100%はほんとうか?
  • A: パケットのキャプチャと再生はできるという意味ではyes。実行時のトレースはとっていないので、スレッドのインターリーブによる部分は再現できないだろう。
  • Q: ext4の例はどのレイヤでやっている?
  • A: ディスクイメージをLKLが解釈している。VFSはつかっていない(ホストOSのVFSのことか?)。
  • Q: LKLのデバッグは?
  • A: gdbでカーネルデバッグできる。
  • archLinuxベースらしい。

image

IIJlab: 自動車とインターネットの融合:IoTは自動車から~日本・シンガポールの先端ITS事例

image

image

18:01

  • 大学時代からずっと自動車とインターネットの研究をしている。
  • DSRC:シンガポール ETCみたいなもの
  • 10月にもどってきて日本で聞くキーワード: IoT,bitdata,AI → まさに自動車自動運転。周期でいえば日本は真夏の次期にきている!
  • ITS: 行動道路交通システム。車両・道路・人をITでつなぐ。
  • 車には300以上のセンサーがある
  • アメリカでは車はweareable computingととらえる人もいる。
  • プローブ情報システム: 渋滞(GPSと速度)とか、ABSでヒヤリハット、ワイパーで天候情報とか。 (~2000年くらいまで)
  • VICSの補完のためにあるのかという質問をよく受けた。
  • 車をインターネットにノードとしてつなぐというコンセプトがわかってもらえなった。
  • ABS動作情報: 温度もあわせて凍結路面とか。 複数メーカーでも動くように国際標準をめさして。
  • ABSの情報は自動車メーカーは出したくない。でもABSのwarningランプ情報は出してくれることになった。
  • スバルはOBD2につなぐ車載機をつくってくれた。
  • 実証実験は秋田大学と北海道大学で(雪がふるところで)
  • 3.11で通れた道マップ。
  • 携帯電話にたよっていたが大規模災害で動かない(停電等)ところもあった→車車間通信も必要。
  • 保険でもつかわれている。運転距離ではなくマイルドな運転をしているかどうかで保険料を決められるメリット。
  • 運転手からしても見られているとおもうとていねいな運転になる。
  • カーテレマティクス系: 自動車メーカー主導。
  • ETC2.0: 一定間隔でプローブ情報をなげている。渋滞で迂回路とおっても事故で一般道におりても料金同じになる。
  • 海外では自動車メーカーはやっておらずプラットフォーム系がほとんど。ノキアのHereとTomTom HD traffic。
  • KEIO-NUS CUTE Center
  • シンガポールは世界一車が高い1000万円くらい。(日本だと200-300万円)
  • 慢性的な渋滞が社会問題になっていた→一般道のロードプライシング(ALS,ERP)
  • ERPの特徴: フリーフロー(ゲートがない)、 mandatory(必須)。
  • 駐車場料金にもつかわれている。
  • 三菱重工が一社独占、メンテナンスでけっこうウハウハなのでは?
  • ERP2: 車を増やしたい。GPSでエリアにはいると携帯網経由で決済。ガントリー不要。メンテ不要。時間で課金とか。
  • 政府としては自動車ビッグデータのプラットホームにしたい狙い。車100%に塔載はインパクトがある。
  • デジタルサイネージで実証実験した。
  • 匿名化して民間に提供するのも考えている。
  • safety(安全), productivity(移動中も自由にできる), efficiency(渋滞をなくす), accessibility(身体障害など)
    • automated driviing(自動運転): V2X 路車(ろしゃ)協調ITS, 日本ではただ1箇所 御台場に設置されている。
    • autonomous driving(自立運転): ドライバーレス。 ITSよりはロボット技術。 これには大きな飛躍が必要。
  • "認知→判断→操作" の判断の部分が自動運転で重要になってくる。
  • ジュネーブ条約/ウィーン協定: article 8ですべての自動車はドライバーをもつこと、ドライバーは操作できなければいないことが定められている。
  • autonomous vehicleでもハンドルとブレーキがついてないとだめとの判決がある。
  • AIに人格権をもたせる方向で話しが進むかも(AIがドライバーとの判断. NHTSA)。 (今日のトップニュース!)
  • 今後の問題:自動運転する車が流れに入ってくることで事故を誘発してしまわないか?
  • 標準化活動: ITS2404? プライバシーが重要。 どこをは走っていたとか知られたくない。
  • 自動車メーカーの中でもAPIを切ってオープンにしていくトレンド。
  • ISOだけでなくW3C(業界団体)でも標準化
  • オープンプラットホーム化がトレンド。秩序あるオープンプラットホーム化。
  • パーソナルデータの扱いが課題。

19:51

  • Q: シンガポールで(ロードプライシングは)いくらかかる?
  • A: $1,$2くらい($1=80円) 。エリアに入るたびに徴収されるのでタクシーには不評。エリアに出入りしなければ金はかからない。
  • Q: 完全自動運転の技術的な障害はなにか?
  • A: 限定されたエリアならなんとかできている。地続きで他の国に入れるようなヨーロッパではまだ難しい。(判断(AI)の部分)
    • これについてはグーグルが先行。リスクヘッジしているメーカは遅れがち。
    • センサーの死角を補うために路側からのデータが必要。今は車載センサーだけ。
  • Q: 使うのはインターネットなのか閉域網なのか?
  • A: いまは併用。ITS用の基盤がある(専用の無線帯域とか)。
    • ITSconnectは760MHzだが、海外ではケータイ用の帯域。
    • 5Gでは車車間通信もターゲットにしているので、どうなるか
    • 国の方針とITUの割り当てと。
  • Q:
  • A: ERPはゲートで。ERP2はゲート不要でGPSで位置情報3Gで。
    • DSRC: 車載機が(不正改造などで)動いていなかったら写真とられて罰金、という世界になる。
    • ERP2で路車間通信だけでなく車車間通信できるようになる。
  • Q: LTEだとか公衆網だと信頼性・安全性はどうか?
  • A: そこはDSRCで。(EPR2でケータイ会社は100万契約純増するウハウハ)

19:05

iijlabセミナー: 静的解析と動的解析を組み合わせたバイナリーコードの制御フロー解析手法

_1000085

_1000087_1000088

  • 3月までは産総研
  • バイナリのマルウェアを研究対象にしていた
    • セキュリティではない
    • サンドボックスで実行してトレースをとるのが一般的。
    • でも特定の条件じゃないと動かないものはパスをすべて調べられない。
  • 最低限、CPU/OS/エントリポイントがわかっている状況で調べる。
  • CFG: 制御フローグラフ。ノードは中はジャンプ命令なしのグラフ。
  • CFGがわかる→抽象実行・モデル検査できる。機械学習もできる。
  • でもCFGをつくるのがむつかしい。
  • 難しさ1
    • 間接ジャンプ(RET命令も含む)には値解析が必要だが、値解析にはCFGが必要。ジレンマ。
    • 一般的には静的決定不能。
  • 難しさ2
    • CALL/RETが信用できない。
    • CALLはRETで戻ってくるとはかぎらない。スタックをいじられてしまうと。
    • 部分構造に切り出して問題を小さくして解くのが基本だが、それができない(どこが関数なのかわからない)。
    • →スタックといった抽象化をしないで単なるメモリアクセスとして解釈する。
  • 展開形制御フロー解析
    • 静的解析(直接ジャンプと宛先のわかる間接ジャンプのみを追う)と動的解析(CFGを実行する。CFG静的解析できてないところかコード書き換えがあるまで)を交互に実施。
    • 静的解析必要ないのでは?→動的解析で通らなかったコードについてもある程度わかるので必要。
    • まず静的解析で広い範囲を調べてわからないところを動的解析する戦略。
    • 動的解析にはBochsとXen(Ether)の両方をつかっている。
  • Win32/Rustok.Bの解析例:
    • ドロッパー: マルウェアをインストールするプログラム。
    • ノード: 253、エッジ: 284を20分で解析
  • 静的解析
    • 直接ジャンプをたどってCFGをつくる
    • 各命令を代入文に変換
    • SSAに変換
    • 要求駆動型定数伝搬
      • Φ関数をつかう(複数のところからJMPでとびこんでくるときレジスタの値が一意に決まらないのを解決するのに)
      • 定数になるまでCFGをさかのぼって展開してゆく
      • 引き算が肝らしい
  • Win32 APIの中身は解析しないでAPIブロックを作成。(マルウェアの解析が目的なので)
  • 文字列解析
    • GetProcAddress(module,procname)みたいなやつを静的解析できる
  • ループは静的解析できない。
  • 動的実行
    • Bochs-python + Ether(Xen)
    • シングルステップ実行
    • ブレークポイント
    • 書き込み検知
    • ステルス性(マルウェアに検出されないように)
  • Bochs-python
    • bochsデバッガインタフェースをフックしてpythonからコントロール
  • Ether
    • Xen3.1ベースにイントロスペクションツール
    • SYSENTERでシステムコールをトレースし
    • ページフォールトでブレークポイント
    • シングルステップ実行にはTFを使用
  • Drakvuf/Libvmi
    • Etherは古いので
    • エージェントがなくてもよい

[2015-07-21 18:29]

Q: 動的解析・静的解析が無限に続いて終らない可能性は?

A: 動的解析にはタイムアウトが必要。

Q: C++のような間接ジャンプのあらしだとおもうが?

A: いちおうできている。

Q: マルウェア以外の用途は?

A: コンパイラの素性がわかっていればヒューリステックがつかえる。組込系でハンドアセンブルしたものとかBIOSとかのバッファオーバーフローの解析とか。

Q: 例外ハンドラで書き換えとか

A: 今は動的解析で対応している

Q: コードインジェクションは?

A: スレッドインジェクション(IE)は実験している。

Q: 開発言語は?

A: Pythonで。インタフェースはCで。メモリは喰うが測ってはない。マルウェアはペイロードが小さい前提がある。同じ計算を何度もしないようにキャッシュしているのでメモリが増えてゆく。

Q: 静的解析でいくつか候補を上げておいて動的解析で絞る方法にしないのは?

A: できるだけ抽象度を上げないで発散しないようにしている。

[2015-07-21 18:40]

iijlabセミナー: 高速ネットワークスタック

_1310589

_1310598

ネクタイしている人がいないようなので,いきなり技術的な話でokらしい。

[2015-04-09 17:31]

Networking Operating System from Scratch towards High-Performance COTS Network Facilities

浅井大史 Hirochika Asai (東京大学)

  • BSDとかのネットワークスタックには贅肉がたくさんあってボトルネックがわかりにくいのでスクラッチで書くことにした。
  • OSは趣味→ドクターのときに仕事化
  • クラウドでコモディティ化→ネットワークがソフトウェア化している
  • forwardingはハードで、routingはソフトで。
  • NFV:仮想マシンをつかうのはオーバヘッドがあってチャレンジングだけど。
  • OSとは?
    • リソースマネージメント
    • ネットワークは周辺機器から中心になってきた
  • スクラッチのイイコト
    • ブラックボックスがない(ハードウェアの限界がわかる)
    • アルゴリズムやアーキテクチャの追求
  • 汎用のCPUをつかう
  • まずはフルルートをあつかえるルーターをつくってみよう
  • VFSR: very fast software router
    • fast packet forwarding (専用チップをつかわずに)
    • fast ip routing table lookup (TCAMをつかわずに)
  • Ethernetでの速いとはどのくらい?
    • 10GbE: 64B 14.88Mpps = 67.2ns/packet
    • 100GbEだとこれの1/10になる。つらい。
    • 40GbEくらはみえてきた。
  • おそいのはなぜ?
    • CPU slow? mem copy? intr overhead?
    • CPUは0.3ns/cpu-cycle (3.3GHz)
    • memcpyは DDR3-1866 ならスループットはたりてる
    • 割り込み処理自体は重くない
  • PCIeのNICはmemory mapped IO (MMIO)でレジスタアクセスする。
    • RAIDカードでは250ns/accessくらいかかると論文に書いてあった。
    • NICで測ってみたらread 392.1ns、write 72.47nsくらいかかった。
    • PMCで測った。100万回くりかえし。
    • RAIDでの値はreadとwriteの平均っぽい。
  • Generic NIC arch
    • ring buffer→Descriptor→Buffer
    • ringバッファの大きさは2の羃とはかぎらないが、divは18cycleくらい。ちょっと最適化の余地。
    • 8個くらいまとめて書くと性能が出る
  • readが遅いので read_txq_head() をなくした by Intel (XL710) write-backをつかうようになった。
    • check_wb_statuss()をつかうように
    • でも性能が出ない。。
    • ring bufferは複数ある。RSS
    • 40G line rateが出ないのはしかたがない(XL710) by Intelさん
  • ポーリングはレイテンシが伸びるといわれているが全力でやれば10us以下になる。(大型のルータよりは速いくらい)(小型のには負ける)
    • テスターで送信してソフトルータでおりかえしてテスターにもどってくる。
    • 全力ポーリングなので電気を喰うけど。
  • CPUのレジスタが増えた(15個)ので割り込みで退避のコストがふえた。push/popはスループット1→30 CPU cycle.
    • レジスタはmust preserveかfreeのどちらかしかない。ABIを変えるしかない。。
    • コアをふやすといけるのは割り込みハンドラのコストがならされるからか?
  • PCIのMMIOが遅い→バルク処理しよう。
  • 割り込みハンドラの処理が無視できない→ポーリング
  • ルーティング: longest prefix match
    • binary radix treeで実現すると深くなったときに遅い+ポインタたどるのおそい
    • 深さを減らすのにmulti arrayのtriにした。メモリへらした。
    • 800k lookupできるようなった。
  • socket APIをなんとかしようということもやっている。
    • 低レイヤーのプログラミングをしなくてもsocketでルータをつくれるように。
    • SOCK_DGRAM + IPPROTO_ETHERNETとか

[2015-04-09 18:16]

Q: OSのはなしはいつごろきける?

A: 半年後くらい?

Q: MACアドレスをバインドするのは?

A: 仮想NICを開くかんじ。2つひらくとルーターに。

Q: ハード割り込みを軽くするだけじゃなだめ?

A: 単純な処理しかしないのに、お決まりの処理が重い。

[2015-04-09 18:20]

_1310590_1310591_1310592_1310593

[2015-04-09 18:20]

Seastar: 高スループットなサーバアプリケーションの為の新しいフレームワーク

浅田拓也 (Cloudius Systems)

  • シースター
  • Cloudius: OSvをつくっているベンチャー企業
  • Avi Kivity: CTO, KVMをつくったひと.
  • seastar: NoSQL, memcachedなどサーバアプリを速くしたい。
    • OSvの経験からAPIを変えずに高速化するのは困難。
    • OSvでも動くが、メインターゲットはlinux.
    • コアがたくさんある、コアの性能は上がらない、NIC/SSDはどんどん速くなっている。
  • 既存のネットワークスタックの問題
    • 共有データがあるので操作コストが大きい。NUMAの場合はCPUからmemが遠いとさらに遅くなる。
    • socket APIの構造的な問題。
  • Seaster
    • shared nothingプログラミングモデルに。
    • CPU間はメッセージパッシング
    • DPDKでカーネルをバイパス
    • no thread(1thread/core), no context sw, no locking.
  • カーネルバイパスの必要性
    • socket APIだとzerocopyがやりにくい(もしくは困難)
    • プロセス処理とアプリが同じコアで実行できずキャッシュコヒーレンシで遅くなったり
    • プロトコル処理のところのロック競合したり
      • ユーザランドとカーネルのきりかえオーバヘッド
  • DPDK
    • intelが中心になって、フレームワーク
    • スレッドはpinされる
    • メモリアロケートも独自。かつhugetlbfsで2MB単位でページをとる。
    • NICはパススルーデバイス経由で直接mmapしてたたく。
    • ポーリング。(最近は割り込みもつかえるようになったらしい)
    • ネットワークスタックは持たない(DPDKの上でやること)
    • アプリにはmbufがとどいたようにみえる。
  • seastarはDPDKの上のネットワークスタック
    • ネットワークIOでシステムコールをつかう必要なし。
    • socket API非互換
    • 対応プロトコル: TCPv4, UDPv4, IPv4,ARP,DHCP
    • packet forwarding用途は考えてない。。。
    • C++14, Future/Promise/Continuationモデルによる非同期API
      • これらをつかってスケジューラを実装。
      • std::のfutureとは別物で独自実装。(汎用じゃなくてよいので: ロックしない、メモリアロケートしない、continuationサポート)
  • C++のlambda式をはじめて見た人は? → 会場の3分の1くらい?
  • Future/Continuation: lambda式で完了時のcallbackを指定する感じ?
  • zero copy RX
    • ドライバからのページが直接みえてるが、scatter-gatherは自動でおこなわれる。
  • zero copy TX
    • TCP windowが開くのを待つfutureとバッファが空くのを待つfutureの2つをつかう。
  • class distributed をつかって複数CPUで実行できる。(threadはpinされる)
    • app.startではcpu0で実行れている。
  • CPU間通信
    • smp::submit_to(neighbor, [key]{return xxx[key]} でneighbor上でreturn xxx[key]が実行される。
  • ポインタはスマートポインタも含めて使わない。std::move()をつかえ。
  • seastartのスケジューラ
    • future/promiseがキューに積まれて、条件が成立したらlambdaが呼ばれる。
    • CPU間でキューが融通されることはない。
    • userland threadとの違いはコンテキスト切り替えがないこと。
  • RSSが使えない環境では1CPUでハッシュ値を計算して分散させるのにも対応。
  • malloc/free/realloc/memalign/new/deleteはフックして独自実装。
  • TCPのコネクションの状態はどう管理する?
    • 同一コネクションのパケットは同一CPUに来るようにしているのでTCP stateを共有する必要はない。
    • ハッシュ値計算はNICがやってくれる。
    • 知らないパケットが届いたらRST。
  • memcachedのaddの実装例
    • addとgetが別CPUになると困る→addのときにsubmit_toで他のCPUに複製しちゃう戦略で解決。(NCPU重複だが共有するよりはまし?)
  • seaster API
    • future/promise/continuation
    • network IO
    • file IO
    • timer
    • HTTP(for server only?)
    • JSON(swagger)
    • RPC (よくわかんね)
    • POSIX API wrapper
    • collectd client (logging daemon)
  • ネットワークバックエントでつかえるもの: DPDK,vhostnet,Xen(OSv),socket
  • DPDK on OSvを実装中 (SR-IOVが対応してるので)
  • OSvがベアメタル上で動くようになるかも?
  • memcachedベンチマーク
    • seastar: リニアに性能が出ている(20コア)
    • stock: マルチスレッド版はスケールしてない。(マルチプロセスの方がまし)
  • 他のDPDK向けのネットワークスタック
    • apiは従来どおりで、ほぼsocket apiとおもわれる。
    • 既存アプリとの互換性は高いとおもわれる。
  • 多言語対応
    • スクリプト言語に対応しても意味なさげ
    • 議論はしているが作業はしてない。募集中。golang?

[2015-04-09 19:26]

Q: SMPのキャッシュコヒーレンシはどうしてる?

A: あとで調べてみる

Q: RSSでフラグメントしてたら?

A: NICのoffloadにたよればたぶんok。

Q: 保護違反したときの対応はどう?

A: 実運用では切り離しするなど対応が必要だろう。

Q: div0したら

A: プロセスが死ぬだけ

[2015-04-09 19:33]

_1310594_1310595_1310596_1310597

久し振りに首藤さんに会った。懇親会に行くかラーメン食って帰るか悩んでた。

_1310599

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

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