Linuxのポーリング処理のコードを読んでみよう 〜初期化編〜 - syuu1228's blog
みんなの大好きなe1000のドライバから、ポーリング処理を追ってみようと思う。 カーネルのバージョンは、fxr.watson.orgに現時点で上がっている2.6.36-rc2。 但し、何故かnet/core/dev.cのページが破損してるので、その部分は配布ソースコードから。 252 module_init(e1000_init_module); ここでe1000_init_module()がモジュールロード時に実行されるよう指定。 ※資料: カーネルモジュール作成メモ e1000_init_moduleでは 241 ret = pci_register_driver(&e1000_driver); ここでe1000_driverを登録、e1000_driver.probeを呼ぶ。 193 static struct pci_driver e1000_driver = { 194 .nam
そんなわけでオレオレifconfigをRubyで書く為のC拡張「ruby-netif」を書いてみました。 - syuu1228's blog
こちら。 こんな感じにRubyスクリプトでNICを設定できるぜいえーい eth = Netif.new("eth0") eth.up eth.mtu = 1000 eth.set_addr("172.0.0.1", "255.255.255.0") puts "addr:#{eth.addr}" puts "netmask:#{eth.netmask}" puts "broadaddr:#{eth.broadaddr}" puts "promisc?:#{eth.promisc?}" puts "up?:#{eth.up?}" puts "eth3 exists?:#{Netif.exists?("eth3")}" 取り敢えずLinuxとFreeBSDでのみ動きます。他のOSは知りません。前回の記事でNetlinkとか騒いでたくせにLinux版でNetlink使ってません（死） どなたかN
各OSのカーネルの行数 - syuu1228's blog
ふと気になったので適当に調べてみる。 調査方法は、各OSのソースコードをダウンロードしてきて、 find . -name "*.[chsS]" -exec cat {} \;|wc -l を実行した（※xnuの場合だけこれに.cppも加えてみた）。 見ての通りいい加減な調べ方なので、あんまり真に受けないように。 ※追記：リクエストにお答えしてsloccountの結果も載せてみます。 OS名 行数 SLOC Linux 3.9.4 15564694 11071422 FreeBSD 9.1 5436430 3826934 DragonFly BSD 3.4.1 2930195 1995729 NetBSD 6.1 5325381 3497216 OpenBSD 5.3 2973206 2104883 xnu 2050.22.13 1261297 798157 UNIX v6 12274 88
パケット受信処理の待ち合わせ部分 - syuu1228's blog
ネットワークスタックの、割り込みコンテキストからプロセスをたたき起こすまでの処理はしっかり読んだつもりなのだが、プロセスコンテキストで寝ている側を深く把握していなかったのでちょっと眺めてみる。 システムコールからプロセスがスリープするまで（UDP） アプリケーションからのシステムコールが最終的にudp_recvmsgを呼ぶところまでの説明は割愛。 udp_recvmsgは__skb_recv_datagramを呼んで、sk->sk_receive_queueに積まれたskbを取り出そうとする。 （skはカーネル内のソケット構造体） この時、パケットがなければwait_for_packetがコールされるが、これが待ち合わせ処理のwait側。 wait_for_packetでは、prepare_to_wait_exclusiveでset_current_stateを呼びcurrent->sta
Kernel/VM Advent Calendar ４日目: Linuxのネットワークスタックのスケーラビリティについて - syuu1228's blog
【お願い】私はLinuxカーネルもネットワーク周りも素人です。ここに書いてある事は間違えている可能性もあるのでおかしいなと思ったらすかさず突っ込んでください。宜しくお願い致します。 今回は、この記事の内容を全面的に見直して、再度Linuxのネットワークスタックのスケーラビリティについてまとめようと思います。 従来のLinuxネットワークスタック＋従来のシングルキューNIC 以下の図は従来のLinuxネットワークスタック＋従来のシングルキューNICで、あるプロセス宛のパケットを受信している時の処理の流れを表している。フォワーディングの場合やプロトコルスタック内の処理は割愛した。 プロセスがシステムコールを発行してからスリープするまで プロセスは、システムコールを通してカーネルにパケットを取りに行く。 パケットはソケット毎のバッファに貯まるようになっているが、バッファが空だったらプロセスはパケ
VIOPS06で「RPS・RFS等最新Linux Kernel事例」と題してお話してきました - syuu1228's blog
はじめに 第一回カーネル／VM探検隊＠関西、第二回日本Vyattaユーザ会ミーティングで行った発表のダイジェスト版です。 詳しく知りたい人はこちらの内容ではなく、第二回日本Vyattaユーザ会ミーティングの動画、資料をみる事をお勧めします。 あと、最新って書いてあるけど割と古い話題です。すんません。 発表資料 従来型のNICとネットワークスタックの組み合わせでは、マルチコア環境においても１つのNICの受信処理は１つのCPUでしか行えません。 これは、NIC上に受信のキューと受信を通知する割り込みが１つしか存在せず、ハードウェアからデバイスドライバまでのレイヤーでは受信処理を並列に行う事が本質的に出来ない事が原因でした。 これが原因で、通信量が多い時にパケット処理の負荷が特定のCPUへ偏ってしまい、CPU数を増やしても性能がスケールしないという問題が発生します。 この問題を解決する為に、１つ
カーネル/VM勉強会@関西 其の参でBHyVeの話をしてきました - syuu1228's blog
なんか関西方面のとても怖い勉強会に参加して、勇気を振り絞ってハイパーバイザーのゆるい話をさせて頂きました＞＜； スライドはこちら（Intel VT, KVMの説明の一部で@oza_x86の資料を使わせて頂いています。oza_kvm先生有り難うございました）： BHyVeってなんや View more presentations from Takuya Asada
Linuxでnetperfとかで負荷かけてる時に/proc/statとかを記録してグラフ化するツールあったらいいなと思ったので作った、という話 - syuu1228's blog
netperfで負荷かけている時にカーネルのstatistics情報取って色々とグラフ作るツールがあったらいいなぁ、と思ったので作った。 今のところperf statで取れるようなCPUのキャッシュの情報とかが取れてないが…とりあえず netperfとかやってる間にログに数値を記録 各CPUの値／合計値／CPU毎の偏り の３パターンで集計 グラフ化 まで出来る。完全自動ではなくてツールが分かれてるが。 取得先はいまのところ/proc化にある以下のファイル： /proc/interrupts /proc/stat /proc/net/netstat /proc/*/sched おまけに、netperfをnプロセス並列で立ち上げるツールもついている。 しかしながら、未だ一切のマニュアルを書いていない… C++とRubyの勉強という面もあって、コードはかなりアレ。 測れるものは増やしていけるとい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
