アドレスからソースコードの位置を探すコマンド - syuu1228's blog
カーネル飛んだ時とか、RIP（EIP）からobjdump -d vmlinuxを見ながら位置を探したりしてたんだけれども、binutilsに含まれてるaddr2line使えばソースコードの行数簡単に見れたのね。 まぁ、これがあるからといってobjdumpでディスアセンブルさせて眺めたいケースが無くなるわけじゃないから、併用した方がいいんだろうけど。 objdumpで探す $ cd ~/linux $ objdump -l -d vmlinux |less (/ ffffffff81525fc0と入力してReturn） ffffffff81525fc0 <dev_queue_xmit>: dev_queue_xmit(): /home/syuu/bcube-linux-stable/net/core/dev.c:2464 ffffffff81525fc0: 55 push %rbp ffff
Google Summer of Code 2011 - syuu1228's blog
FreeBSDプロジェクトでGSoCにApplyしたら採択してもらえました。 Proposalはこちら： http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/syuu1228/1 内容としては、最近調べて回ってるネットワークIO周りの延長線上で、tcpdumpやらwiresharkやらに使われるBPFにMultiqueue NICサポートを追加するという作業です。 BPFインスタンス毎にどのキューを取りに行くか設定して、１スレッド：１キュー：１CPUにしてキューへ分散されたパケットを効率よくダンプしてみたり、RSS周りのデバッグや調査で各キューに着てるパケットを可視化する手段としてみたり出来る予定。 また、テストの一環としてMultiqueueエミュレーション出来るtapデバイスを作ってBPFのテストやRSS
FreeBSDのパケットディスパッチについて - syuu1228's blog
探検隊での発表や、FreeBSD/i386のパケット受信フロー - かーねる・う゛いえむにっきの補足。 まず、話の前提のおさらいから。 マルチコア環境でネットワーク受信処理をスケールさせるには、NICに届く沢山のパケットを複数のコアへばらまいて並列に処理させる必要がある ランダムにばらまくよりも、同一フローに属するパケットは同一コアへ割り当てる方がデータローカリティが高くなりキャッシュミスが減るので性能が上がると考えられている 複数コアへばらまく仕組みとして、二通りの方式がある。 RSS: ハードウェアで行う。パケットヘッダのハッシュ値を計算してハッシュテーブルを引き、割り当てられたCPUへ割り込みを行う。受信キューはCPU毎に独立している。 RPS(Linux): ソフトウェアで行う。NICからの割り込みは常に特定のCPUへ入るが、受信処理を行うCPU上でパケットヘッダのハッシュ値を計算
Receive-Side Scalingについての調査メモ - syuu1228's blog
Kernel/VM Advent Calendar ４日目: Linuxのネットワークスタックのスケーラビリティについて - かーねる・う゛いえむにっきで書いたReceive-Side Scalingの記述が未だ理解が足りず不正確だと思ったので、調べ直してみてる所。 Multi-queueなNICってなに RPS提案のメールにこんな事が書いてある： This effectively emulates in software what a multi-queue NIC can provide, but is generic requiring no device support. 要約すると「multi-queue NICが提供している機能をソフトウェアエミュレートするのがRPS」 →じゃあmulti-queueなNICってどれで、どんな機能を提供してるんだろう？ それらしいNICを探して
Kernel/VM Advent Calendar ４日目: Linuxのネットワークスタックのスケーラビリティについて - syuu1228's blog
【お願い】私はLinuxカーネルもネットワーク周りも素人です。ここに書いてある事は間違えている可能性もあるのでおかしいなと思ったらすかさず突っ込んでください。宜しくお願い致します。 今回は、この記事の内容を全面的に見直して、再度Linuxのネットワークスタックのスケーラビリティについてまとめようと思います。 従来のLinuxネットワークスタック＋従来のシングルキューNIC 以下の図は従来のLinuxネットワークスタック＋従来のシングルキューNICで、あるプロセス宛のパケットを受信している時の処理の流れを表している。フォワーディングの場合やプロトコルスタック内の処理は割愛した。 プロセスがシステムコールを発行してからスリープするまで プロセスは、システムコールを通してカーネルにパケットを取りに行く。 パケットはソケット毎のバッファに貯まるようになっているが、バッファが空だったらプロセスはパケ
じゃあ、Linuxのネットワークスタックはどうなのん？ - syuu1228's blog
この記事の続きになる訳だが、いくらSolaris最強って言っても、大手メーカーがこぞってつつき回して性能改善したり機能追加したりしてるはずのLinuxで何も対策が打たれてない訳が無いよね。じゃあどうなってるんだろう、って話。 例によって、Linuxとか全ッ然知らないので、間違ってたらツッコミ下さい。 ポーリングとパケット処理のパス 殆どここで解説し尽くされてる。 Linuxにも動的ポーリングの実装（Solarisで言ってる動的ポーリングと同じものとは限らないが…）があって、NAPIとか呼ばれてるらしい。 NAPIを実装するドライバでは、こんな手順で受信処理を行ってる。 ハードウェア割り込みを受け、割り込みハンドラを起動 ハードウェア割り込みを禁止、ポーリングをスケジュール ソフトウェア割り込み経由でNAPIのポーリングルーチンを起動 ドライバにポーリングを指示 この時、適切な性能を確保する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
