linuxの最近のブログ記事

2010年9月18日

CONCURRENCY_LEVELを上げてkernel buildするとkernelが不安定になる件

先日のエントリで、kernel build中(というより終了後)にNMI関連のカーネルログを吐き出してて動作が数分かたまるという現象が発生した件について。最初、久々に取り付けたSSD(X25-V)が壊れてしまってたかと思ったけど全然そんなことはなく、CONCURRENCY_LEVELを上げたことによって発生していたことが分かった。今までkernelなんて出来ればいいやくらいにしか思ってなかったから、CONCURRENCY_LEVELをいじって作業することなんてなかったなあそういえば。

SSDを取り外してやってみても発生したものの、CONCURRENCY_LEVELを無指定なら発生せず。CONCURRENCY_LEVELは8でも4でも発生して2では出なかった。この違いは何かな。何か大切なor初歩的なkernelオプションの指定が漏れてるだけだったり、な予感が。 

Sep 17 23:29:33 mary kernel: [ 1616.681497] INFO: rcu_sched_state detected stalls on CPUs/tasks: { 7} (detected by 6, t=67358 jiffies)
Sep 17 23:29:33 mary kernel: [ 1616.681821] sending NMI to all CPUs:
Sep 17 23:29:33 mary kernel: [ 1616.681884] NMI backtrace for cpu 0
Sep 17 23:29:33 mary kernel: [ 1616.681886] CPU 0 
Sep 17 23:29:33 mary kernel: [ 1616.681887] Modules linked in: ipv6 ext2 mbcache sbp2 ieee1394 loop snd_hda_codec_nvhdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc parport video output snd_pcm snd_timer snd i2c_i801 i2c_core soundcore tpm_tis tpm snd_page_alloc tpm_bios button processor pcspkr evdev xfs exportfs sd_mod ata_piix ata_generic libata scsi_mod ide_pci_generic e1000e ide_core ehci_hcd thermal fan thermal_sys [last unloaded: scsi_wait_scan]
Sep 17 23:29:33 mary kernel: [ 1616.681908] 
Sep 17 23:29:33 mary kernel: [ 1616.681910] Pid: 0, comm: swapper Not tainted 2.6.35.4 #1 DH55TC/        
Sep 17 23:29:33 mary kernel: [ 1616.681911] RIP: 0010:[<ffffffff81009fdc>]  [<ffffffff81009fdc>] mwait_idle_with_hints+0xaa/0xb2
Sep 17 23:29:33 mary kernel: [ 1616.681916] RSP: 0018:ffffffff813c9e88  EFLAGS: 00000046
Sep 17 23:29:33 mary kernel: [ 1616.681918] RAX: 0000000000000020 RBX: 11d1dc774d79458d RCX: 0000000000000001
Sep 17 23:29:33 mary kernel: [ 1616.681919] RDX: 0000000000000000 RSI: ffffffff813c9fd8 RDI: 0000000000000020
Sep 17 23:29:33 mary kernel: [ 1616.681921] RBP: 0000000000000003 R08: ffffffffa01d745c R09: ffff88023f26300c
Sep 17 23:29:33 mary kernel: [ 1616.681923] R10: 0000000100000000 R11: ffffffff813c9e74 R12: 0000000000000020
Sep 17 23:29:33 mary kernel: [ 1616.681925] R13: 0000000000000001 R14: ffffffff814c87e0 R15: 0000000001592df8
Sep 17 23:29:33 mary kernel: [ 1616.681927] FS:  0000000000000000(0000) GS:ffff880001800000(0000) knlGS:0000000000000000
Sep 17 23:29:33 mary kernel: [ 1616.681930] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Sep 17 23:29:33 mary kernel: [ 1616.681932] CR2: 00007f75164a7000 CR3: 000000000141b000 CR4: 00000000000006f0
Sep 17 23:29:33 mary kernel: [ 1616.681934] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Sep 17 23:29:33 mary kernel: [ 1616.681936] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Sep 17 23:29:33 mary kernel: [ 1616.681938] Process swapper (pid: 0, threadinfo ffffffff813c8000, task ffffffff81423020)
Sep 17 23:29:33 mary kernel: [ 1616.681940] Stack:
Sep 17 23:29:33 mary kernel: [ 1616.682044]  ffff88023f263020 11d1dc774d79458d ffff88023f263500 ffff88023f263020
Sep 17 23:29:33 mary kernel: [ 1616.682047] <0> ffff88023f263000 ffffffffa01d73b5 0000000000000000 00000000000001eb
Sep 17 23:29:33 mary kernel: [ 1616.682050] <0> 0000000000000000 ffff88023f263150 ffff88023f263020 6db6db6db6db6db7
Sep 17 23:29:33 mary kernel: [ 1616.682054] Call Trace:
Sep 17 23:29:33 mary kernel: [ 1616.682161]  [<ffffffffa01d73b5>] ? acpi_idle_enter_bm+0x204/0x2e2 [processor]
Sep 17 23:29:33 mary kernel: [ 1616.682166]  [<ffffffff812225e5>] ? cpuidle_idle_call+0x95/0xf4
Sep 17 23:29:33 mary kernel: [ 1616.682169]  [<ffffffff81001db1>] ? cpu_idle+0x59/0x91
Sep 17 23:29:33 mary kernel: [ 1616.682173]  [<ffffffff81491140>] ? early_idt_handler+0x0/0x71
Sep 17 23:29:33 mary kernel: [ 1616.682176]  [<ffffffff81491d05>] ? start_kernel+0x3a0/0x3ac
Sep 17 23:29:33 mary kernel: [ 1616.682180]  [<ffffffff814a92be>] ? __reserve_early+0xa4/0xba
Sep 17 23:29:33 mary kernel: [ 1616.682183]  [<ffffffff814913a2>] ? x86_64_start_kernel+0xf9/0x106
Sep 17 23:29:33 mary kernel: [ 1616.682185] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
Sep 17 23:29:33 mary kernel: [ 1616.688199] Call Trace:
Sep 17 23:29:33 mary kernel: [ 1616.688202]  [<ffffffffa01d73b5>] ? acpi_idle_enter_bm+0x204/0x2e2 [processor]
Sep 17 23:29:33 mary kernel: [ 1616.688206]  [<ffffffff812225e5>] ? cpuidle_idle_call+0x95/0xf4
Sep 17 23:29:33 mary kernel: [ 1616.688208]  [<ffffffff81001db1>] ? cpu_idle+0x59/0x91
Sep 17 23:29:33 mary kernel: [ 1616.688211]  [<ffffffff81491140>] ? early_idt_handler+0x0/0x71
Sep 17 23:29:33 mary kernel: [ 1616.688214]  [<ffffffff81491d05>] ? start_kernel+0x3a0/0x3ac
Sep 17 23:29:33 mary kernel: [ 1616.688216]  [<ffffffff814a92be>] ? __reserve_early+0xa4/0xba
Sep 17 23:29:33 mary kernel: [ 1616.688219]  [<ffffffff814913a2>] ? x86_64_start_kernel+0xf9/0x106
Sep 17 23:29:33 mary kernel: [ 1616.688222] Pid: 0, comm: swapper Not tainted 2.6.35.4 #1

Hironobu Koura (02:09) | コメント(0) | トラックバック(0)

2010年9月 9日

くらべてみよう - HDDとSSDでkernel build

こないだやったベンチマークには反省もあって、せっかくやったのに条件変えての追試とか考察とかもほったらかしでやりっ放しだったのよね。特に同スペックにしてHDDとSSDで構成を違えたnellyとshirleyの間の性能差なんて、格好の調査材料だったのに、すぐにnellyをルータに投入してしまったのでテストどころじゃなくなったという。

そんなところに@H_Holonさんがこんなこと言うもんで。

【緩募】 build環境を HDDから SSDにかえたときの体感比較10:40 PM Sep 4th via YoruFukurouH.Holon
H_Holon

「ほんのり」とか「まったり」とか「それでいてしつこくない」とか RT @H_Holon: 【緩募】 build環境を HDDから SSDにかえたときの体感比較10:44 PM Sep 4th via Tweetie for MacHironobu Koura
hironobu_k

...

なんかビミョウに落ちきらない大変残念な返しをしてしまい反省の意味を込めて実地で計測してみようと相成った次第。手近にread/write負荷を掛けられるということで、linuxカーネルの再構築など。

maryは4coreのHT付きなので環境変数CONCURRENCY_LEVELを8にして実行、timeをとりました。(正確にはビルド途中のinclude/generated云々で止まっちゃうところまでの時間です。) 

hironobu@mary:/mnt/tmp/linux-2.6.35.4$ export CONCURRENCY_LEVEL=8
hironobu@mary:/mnt/tmp/linux-2.6.35.4$ time fakeroot make-kpkg --initrd --revision=foursics.0.1 kernel_image
exec make -f /usr/share/kernel-package/ruleset/minimal.mk debian DEBIAN_REVISION=foursics.0.1  INITRD=YES 
exec debian/rules  DEBIAN_REVISION=foursics.0.1  INITRD=YES  kernel_image 
...

real    7m18.346s
user    44m56.457s
sys     3m40.902s

real    8m31.498s
user    43m20.899s
sys     3m34.913s

上がSSD(X25-V 40GB)、下がHDD(HDS721050CLA362)です。並列度8なので、userとsysの時間もx8になってるんですね。で、それらの時間とrealが連動してないのはこれ注目ですな。しかしビルドしてる間に下みてえなkernelログが出たんだよなあ...。何だこれ。 

 mary kernel: [49874.515294] Stack:
 mary kernel: [49874.515301] Call Trace:
 mary kernel: [49874.515323] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
 mary kernel: [49874.515461] Stack:
 mary kernel: [49874.515488] Call Trace:
 mary kernel: [49874.515516] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
 mary kernel: [49874.515742] Uhhuh. NMI received for unknown reason 00 on CPU 1.
 mary kernel: [49874.515744] Do you have a strange power saving mode enabled?
 mary kernel: [49874.515745] Dazed and confused, but trying to continue
 mary kernel: [49874.515854] Stack:
 mary kernel: [49874.515878] Call Trace:
 mary kernel: [49874.515912] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
 mary kernel: [49874.516198] Stack:
 mary kernel: [49874.516265] Call Trace:
 mary kernel: [49874.516295] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
 mary kernel: [49874.516523] Uhhuh. NMI received for unknown reason 00 on CPU 2.
 mary kernel: [49874.516525] Do you have a strange power saving mode enabled?
 mary kernel: [49874.516526] Dazed and confused, but trying to continue
 mary kernel: [49874.516658] Stack:
 mary kernel: [49874.516686] Call Trace:
 mary kernel: [49874.516716] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
 mary kernel: [49874.516989] Uhhuh. NMI received for unknown reason 00 on CPU 3.
 mary kernel: [49874.516991] Do you have a strange power saving mode enabled?
 mary kernel: [49874.516992] Dazed and confused, but trying to continue
 mary kernel: [49874.517115] Stack:
 mary kernel: [49874.517142] Call Trace:
 mary kernel: [49874.517171] Code: 65 48 8b 34 25 48 b5 00 00 48 89 ca 48 8d 86 38 e0 ff ff 0f 01 c8 0f ae f0 f6 86 38 e0 ff ff 08 75 09 4c 89 e0 4c 89 e9 0f 01 c9 <59> 5b 5d 41 5c 41 5d c3 53 65 48 8b 04 25 48 b5 00 00 f6 80 38 
 mary kernel: [49874.517402] Uhhuh. NMI received for unknown reason 00 on CPU 4.
 mary kernel: [49874.517404] Do you have a strange power saving mode enabled?
 mary kernel: [49874.517405] Dazed and confused, but trying to continue
 mary kernel: [49874.517537] Stack:
 mary kernel: [49874.517565] Call Trace:
 mary kernel: [49874.517590] Code: d8 5b 5d 41 5c 41 5d 41 5e c3 53 48 83 ec 20 e8 6c 8b e3 ff 48 89 c3 fb 66 0f 1f 44 00 00 65 48 8b 04 25 48 b5 00 00 eb 02 f3 90 <f6> 80 38 e0 ff ff 08 74 f5 e8 47 8b e3 ff 48 89 c7 48 29 df e8 
 mary kernel: [49874.517814] Stack:
 mary kernel: [49874.517823] Call Trace:
 mary kernel: [49874.517824]  <IRQ> 
 mary kernel: [49874.517871]  <EOI> 
 mary kernel: [49874.517890] Code: 41 55 49 89 fd 41 54 55 53 48 83 ec 30 65 8b 1c 25 80 d3 00 00 66 66 90 0f ae e8 e8 c0 0b e9 ff 66 90 4c 63 e0 66 66 90 0f ae e8 <e8> b0 0b e9 ff 66 90 48 63 f0 48 89 f0 4c 29 e0 4c 39 e8 73 28 
 mary kernel: [49874.518035] Uhhuh. NMI received for unknown reason 00 on CPU 5.
 mary kernel: [49874.518038] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518040] Dazed and confused, but trying to continue
 mary kernel: [49874.518086] Stack:
 mary kernel: [49874.518093] Call Trace:
 mary kernel: [49874.518094]  <IRQ> 
 mary kernel: [49874.518122]  <EOI> 
 mary kernel: [49874.518134] Uhhuh. NMI received for unknown reason 00 on CPU 6.
 mary kernel: [49874.518135] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518139] Dazed and confused, but trying to continue
 mary kernel: [49874.518140] Code: 90 0f ae e8 e8 c0 0b e9 ff 66 90 4c 63 e0 66 66 90 0f ae e8 e8 b0 0b e9 ff 66 90 48 63 f0 48 89 f0 4c 29 e0 4c 39 e8 73 28 f3 90 <65> 8b 2c 25 80 d3 00 00 39 eb 74 d7 49 29 f4 4d 01 e5 66 66 90 
 mary kernel: [49874.518250] Uhhuh. NMI received for unknown reason 00 on CPU 7.
 mary kernel: [49874.518252] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518254] Dazed and confused, but trying to continue
 mary kernel: [49874.518293] Stack:
 mary kernel: [49874.518299] Call Trace:
 mary kernel: [49874.518299]  <IRQ> 
 mary kernel: [49874.518340]  <EOI> 
 mary kernel: [49874.518360] Code: ff c8 74 03 e6 80 c3 e6 ed c3 bf 8e 21 00 00 e9 be f4 16 00 c3 90 90 90 89 f8 e6 70 e4 71 c3 89 f0 e6 70 40 88 f8 e6 71 c3 0f 31 <89> c1 48 89 d0 48 c1 e0 20 89 ca 48 09 d0 c3 41 55 41 54 53 48 
 mary kernel: [49874.518497] Uhhuh. NMI received for unknown reason 00 on CPU 2.
 mary kernel: [49874.518499] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518501] Dazed and confused, but trying to continue
 mary kernel: [49874.518544] Stack:
 mary kernel: [49874.518552] Call Trace:
 mary kernel: [49874.518562] Code: ff 07 00 00 48 c7 c7 80 34 01 00 65 48 8b 04 25 78 d3 00 00 48 01 c7 e9 11 08 00 00 eb e6 90 9c 58 c3 57 9d c3 fa c3 fb c3 fb f4 <c3> f4 c3 0f 06 c3 0f 20 c0 c3 0f 22 c7 c3 0f 20 d0 c3 0f 22 d7 
 mary kernel: [49874.518620] Uhhuh. NMI received for unknown reason 00 on CPU 3.
 mary kernel: [49874.518621] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518622] Dazed and confused, but trying to continue
 mary kernel: [49874.518694] Uhhuh. NMI received for unknown reason 00 on CPU 4.
 mary kernel: [49874.518696] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518697] Dazed and confused, but trying to continue
 mary kernel: [49874.518796] Uhhuh. NMI received for unknown reason 00 on CPU 5.
 mary kernel: [49874.518797] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518798] Dazed and confused, but trying to continue
 mary kernel: [49874.518891] Uhhuh. NMI received for unknown reason 00 on CPU 6.
 mary kernel: [49874.518892] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518893] Dazed and confused, but trying to continue
 mary kernel: [49874.518990] Uhhuh. NMI received for unknown reason 00 on CPU 7.
 mary kernel: [49874.518991] Do you have a strange power saving mode enabled?
 mary kernel: [49874.518992] Dazed and confused, but trying to continue

Hironobu Koura (16:14) | コメント(0) | トラックバック(0)

2010年8月19日

カーネル再構築時にDebianパッケージ化してさらにそこにe1000eドライバの最新を組み込んでおきたいので

5台で運用してるdebianサーバのカーネルを合わせるために、うち1台でビルドしたカーネルはdebパッケージにして配布してるのですがね。e1000eドライバはIntelのダウンロードセンターから取り寄せて組み込んでいるので、ちょっと手順が複雑な上に間隔が空くとすぐに忘れちゃうんですよ。いやだわおぢいちゃんたら晩ご飯ならさっき食べたでしょ。

なお、前段階として

とかも忘れないでね。良い子のお約束だゾ。 

$ tar jxf linux-x.y.z.tar.bz2 -C /usr/src
$ tar zxf e1000e-p.q.r.tar.gz -C ~
$ cd /usr/src/linux-x.y.z
$ make menuconfig
$ make-kpkg clean
$ fakeroot make-kpkg --initrd --revision=abc.0.1 kernel_image
(ここで途中、include/generatedに生成された？ヘッダファイルがinclude/linuxに無いのでとエラーが起こるので)
$ cd ~/e1000e-p.q.r/src/
$ env BUILD_KERNEL=x.y.z make
$ cd /usr/src/linux-x.y.z/drivers/net/
$ mv ./e1000e ~/e1000e.old && cp -r ~/e1000e-p.q.r/src ./e1000e
$ cd ../../include/generated/
$ mv * ../linux/
$ cd ../..
$ fakeroot make-kpkg --initrd --revision=abc.0.1 kernel_image
(で、~hoge/直下にlinux-image-x.y.z_abc.0.1_amd64.debとか何か出来てないか確認したまへ)

で、完成のもより。

Hironobu Koura (23:15) | コメント(0) | トラックバック(0)

2010年5月18日

おうちでgangliaとか

結局スイッチの件は無事発注しなおしができましたよということで、気を取り直して次のネタ。

せっかく何台もサーバを揃えたのでやってみたいじゃないですかとgangliaを入れてみた。

http://ganglia.sourceforge.net/
Ganglia Monitoring System

インストール時につっかえたのは「date.timezone」の設定を明示的に行っておかないとphpがだだをこねてwarningを出しまくると言う点。ちなみにうちのphpは現時点最新の5.3.2。php.iniを作成してそこで指定しておくことにした。

あと、GDモジュールが必要。と言っても円グラフを少し入れたりするのに使ってる程度だけど、うちではphpのconfigureしてたときに--with-gdオプションを付けてなかったこともあってインストールされていなかった模様。GDはdebパッケージなので(libgd2-xpm)、開発用パッケージ(libgd2-xpm-dev)も忘れずにインストール。その後--with-gd付きで再度ビルドしなおして事なきを得た。

ganglia自体もsqueezeには入ってるらしいganglia-webfrontendパッケージはまだlennyには降りて来ていないっぽく、またdeb自体もバージョン2.5.xとやや古めで設定ファイルの書式なども違っていたので、3.1.7をこちらもソースからビルドしてインストール。こちらもそんなに引っかかること無くインストールできました。　

Hironobu Koura (22:59) | コメント(0) | トラックバック(0)

2010年5月14日

複数インタフェイスを持つサーバ上でxl2tpdを動かしたときにね。

例のLinuxルータ(nelly)、NICが2つ付いてる訳なんですけど、っていうかpppoeかましてしかもマルチセッションしてるからインタフェイスの数がまあ5-6個くらいはある形になってるんです。で、ppp0でOCN、ppp1でwakwakっていうマルチセッションをやってて、wakwakの方が固定IPアドレス付けてまして、っていう構成なんですがね。

そこに外からVPNを掛けたいとしましょうや。VPNの受け口にはまあOCNは非固定アドレスなんでDynamic DNSでもやってない限り使いにくい。なんでwakwakの方でVPNの受信をさせようかとか思うとですね、L2TP+IPSECでやってるとxl2tpdがよろしくないんです。IPsecのネゴシエートが終わってL2TPに処理が移るとですね、xl2tpdさん何を血迷ったか、ppp1経由で受け取ったはずのL2TPクライアントからのリクエストに対して、default routeになってるppp0経由でレスポンス返そうとするんですわ。したらあんさん、L2TPクライアントからすればリクエスト送ったはずのサーバアドレス(=ppp1)と違うアドレス(=ppp0)からレスポンスが返ってきたって知るかーってなもんですよ。いやー、参りましたわー。orz

というわけでこれ、直しました。受信IPアドレスを使って打ち返すように、sendmsg()でmsg_controlにIP_PKTINFOを仕込んで設定するようにしました。xl2tpd v1.2.4に対するパッチとして適宜適用して下さい。本来なら同じmsg_controlを使うIP_IPSEC_REFINFOと併用した際の挙動とかも確かめなきゃなんですけど、うちでは使ってないのでやってません;-)。パッチの適用についてはat your own riskでよろしくでございます。詳細は追って。

ファイル: xl2tpd-1.2.4.patch 

diff -uNr ./xl2tpd-1.2.4.orig/call.c ./xl2tpd-1.2.4/call.c
--- ./xl2tpd-1.2.4.orig/call.c  2009-03-09 08:25:30.000000000 +0900
+++ ./xl2tpd-1.2.4/call.c       2010-05-14 03:34:40.461125516 +0900
@@ -618,7 +618,7 @@
 }
 
 struct call *get_call (int tunnel, int call, unsigned int addr, int port,
-                      IPsecSAref_t refme, IPsecSAref_t refhim)
+                      unsigned int localaddr, IPsecSAref_t refme, IPsecSAref_t refhim)
 {
     /*
      * Figure out which call struct should handle this. 
@@ -695,9 +695,11 @@
         };
         st->peer.sin_family = AF_INET;
         st->peer.sin_port = port;
+       st->local.sin_family = AF_INET;
        st->refme  = refme;
        st->refhim = refhim;
         bcopy (&addr, &st->peer.sin_addr, sizeof (addr));
+        bcopy (&localaddr, &st->local.sin_addr, sizeof (localaddr));
         st->next = tunnels.head;
         tunnels.head = st;
         tunnels.count++;
diff -uNr ./xl2tpd-1.2.4.orig/call.h ./xl2tpd-1.2.4/call.h
--- ./xl2tpd-1.2.4.orig/call.h  2009-03-09 08:25:30.000000000 +0900
+++ ./xl2tpd-1.2.4/call.h       2010-05-14 03:34:52.625126441 +0900
@@ -98,7 +98,7 @@
 extern void push_handler (int);
 extern void toss (struct buffer *);
 extern struct call *get_call (int tunnel, int call, unsigned int addr,
-                             int port,
+                             int port, unsigned int localaddr,
                              IPsecSAref_t refme, IPsecSAref_t refhim);
 extern struct call *get_tunnel (int, unsigned int, int);
 extern void destroy_call (struct call *);
diff -uNr ./xl2tpd-1.2.4.orig/l2tp.h ./xl2tpd-1.2.4/l2tp.h
--- ./xl2tpd-1.2.4.orig/l2tp.h  2009-03-09 08:25:30.000000000 +0900
+++ ./xl2tpd-1.2.4/l2tp.h       2010-05-14 03:38:04.172126651 +0900
@@ -146,6 +146,7 @@
     unsigned short port;        /* Port on remote end */
 #else
     struct sockaddr_in peer;    /* Peer's Address */
+    struct sockaddr_in local;   /* Local's Address */
 #endif
     int debug;                  /* Are we debugging or not? */
     int nego;                   /* Show Negotiation? */
diff -uNr ./xl2tpd-1.2.4.orig/network.c ./xl2tpd-1.2.4/network.c
--- ./xl2tpd-1.2.4.orig/network.c       2009-03-09 08:25:30.000000000 +0900
+++ ./xl2tpd-1.2.4/network.c    2010-05-14 04:03:15.057126011 +0900
@@ -77,6 +77,11 @@
 
            gconfig.ipsecsaref=0;
     }
+    arg=1;
+    if (setsockopt(server_socket, IPPROTO_IP, IP_PKTINFO, &arg, sizeof(arg)) != 0) {
+           l2tp_log(LOG_CRIT, "setsockopt recvref[%d]: %s\n", IP_PKTINFO, strerror(errno));
+    }
+
 #else
        l2tp_log(LOG_INFO, "No attempt being made to use IPsec SAref's since we're not on a Linux machine.\n");
 
@@ -257,8 +262,8 @@
 
 void udp_xmit (struct buffer *buf, struct tunnel *t)
 {
-    struct cmsghdr *cmsg;
-    char cbuf[CMSG_SPACE(sizeof (unsigned int))];
+    struct cmsghdr *cmsg = NULL;
+    char cbuf[CMSG_SPACE(sizeof (unsigned int)) + CMSG_SPACE(sizeof(struct in_pktinfo))];
     unsigned int *refp;
     struct msghdr msgh;
     int err;
@@ -288,6 +293,28 @@
 
        msgh.msg_controllen = cmsg->cmsg_len;
     }
+
+    if (t->local.sin_addr.s_addr) {
+        if(gconfig.debug_network) {
+                l2tp_log(LOG_DEBUG,"sending with setting source address saref=%s\n", inet_ntoa(t->local.sin_addr));
+        }
+
+        struct in_pktinfo* ipi;
+        msgh.msg_controllen = sizeof(cbuf);
+
+        cmsg = (cmsg ? CMSG_NXTHDR(&msgh, cmsg) : CMSG_FIRSTHDR(&msgh));
+        cmsg->cmsg_level = IPPROTO_IP;
+        cmsg->cmsg_type  = IP_PKTINFO;
+        cmsg->cmsg_len   = CMSG_LEN(sizeof(struct in_pktinfo));
+
+        ipi = (struct in_pktinfo*)CMSG_DATA(cmsg);
+        ipi->ipi_ifindex = 0;
+        ipi->ipi_addr.s_addr = 0;
+        bcopy(&t->local.sin_addr, &ipi->ipi_spec_dst, sizeof(ipi->ipi_spec_dst));
+
+        msgh.msg_controllen = CMSG_SPACE(sizeof(struct in_pktinfo));
+    }
+
     
     iov.iov_base = buf->start;
     iov.iov_len  = buf->len;
@@ -388,6 +415,8 @@
     struct iovec iov;
     char cbuf[256];
     unsigned int refme, refhim;
+    struct cmsghdr *cmsg;
+    struct in_pktinfo* inpkt = NULL;
 
     /* This one buffer can be recycled for everything except control packets */
     buf = new_buf (MAX_RECV_SIZE);
@@ -478,7 +507,6 @@
 
            /* extract IPsec info out */
            if(gconfig.ipsecsaref) {
-                   struct cmsghdr *cmsg;
                    /* Process auxiliary received data in msgh */
                    for (cmsg = CMSG_FIRSTHDR(&msgh);
                         cmsg != NULL;
@@ -494,6 +522,12 @@
                    }
            }
 
+            for (cmsg = CMSG_FIRSTHDR(&msgh); cmsg != NULL; cmsg = CMSG_NXTHDR(&msgh,cmsg)) {
+                if (cmsg->cmsg_level == IPPROTO_IP && cmsg->cmsg_type == IP_PKTINFO) {
+                    inpkt = (struct in_pktinfo*)CMSG_DATA(cmsg); 
+                }
+            }
+
            /*
             * some logic could be added here to verify that we only
             * get L2TP packets inside of IPsec, or to provide different
@@ -517,7 +551,7 @@
            }
            if (!
                (c = get_call (tunnel, call, from.sin_addr.s_addr,
-                              from.sin_port, refme, refhim)))
+                              from.sin_port, (inpkt ? inpkt->ipi_spec_dst.s_addr : 0), refme, refhim)))
            {
                if ((c =
                     get_tunnel (tunnel, from.sin_addr.s_addr,
diff -uNr ./xl2tpd-1.2.4.orig/xl2tpd.c ./xl2tpd-1.2.4/xl2tpd.c
--- ./xl2tpd-1.2.4.orig/xl2tpd.c        2009-03-09 08:25:30.000000000 +0900
+++ ./xl2tpd-1.2.4/xl2tpd.c     2010-05-14 03:37:08.664125809 +0900
@@ -599,7 +599,7 @@
      * to do IPsec properly here, we need to set a socket policy,
      * and/or communicate with pluto.
      */
-    tmp = get_call (0, 0, addr, port, IPSEC_SAREF_NULL, IPSEC_SAREF_NULL);
+    tmp = get_call (0, 0, addr, port, 0, IPSEC_SAREF_NULL, IPSEC_SAREF_NULL);
     if (!tmp)
     {
         l2tp_log (LOG_WARNING, "%s: Unable to create tunnel to %s.\n", __FUNCTION__,

Hironobu Koura (03:58) | コメント(0) | トラックバック(0)

2010年5月12日

UnixBenchの中身を見てみるよ

さて、ここまでUnix Benchをただ走らすだけ走らせてみたけど、内容にもちゃんと踏み込まないと逝けませんよねということでソースの中身を検証してみます。

まず何より気になっていたのがAMD系からIntel系に切り替えて歴然と違いが出たSystem Call Overhead。Unix Benchのテストはtarballを解凍した中にある"Run"スクリプトから全てが始まりますが、こいつは配下にpgmsディレクトリを持っていて、そこに配置された各テストプログラムを起動するだけです。

Runスクリプトの中ではそれらテストプログラムとその説明や起動時のオプション(何回・何秒ループさせるとか、テストの種類を指定する)の情報をハッシュで保持しています。 

# Individual parameters for all benchmarks.
my $testParams = {

    ##########################
    ## System Benchmarks    ##
    ##########################

    "dhry2reg" => {
        "logmsg" => "Dhrystone 2 using register variables",
        "cat"    => 'system',
        "options" => "10",
        "repeat" => 'long',
    },
    "whetstone-double" => {
        "logmsg" => "Double-Precision Whetstone",
        "cat"    => 'system',
        "repeat" => 'long',
    },
    "syscall" => {
        "logmsg" => "System Call Overhead",
        "cat"    => 'system',
        "repeat" => 'long',
        "options" => "10",
    },
    "context1" => {
        "logmsg" => "Pipe-based Context Switching",
        "cat"    => 'system',
        "repeat" => 'long',
        "options" => "10",
    },
...
};

"System Call Overhead"、つまりsyscallの項目に格納されていることになります。そしてこの場合、"syscall"のキーが起動するテストプログラム名に対応付けされていて、それは(unixbenchディレクトリ)/pgms/syscallとなります。またこれのソースが(unixbenchディレクトリ)/src/syscall.cとなります。

また起動時の引数はさらに下位ハッシュの"options"に格納されていますがこちらは"10"となっています。つまりここから"System Call Overhead"のテストを起動するときは、コマンドラインで仮定すれば"./pgms/syscall 10"として起動することになります。 

        switch (test[0]) {
        case 'm':
           while (1) {
                close(dup(0));
                getpid();
                getuid();
                umask(022);
                iter++;
           }
           /* NOTREACHED */
        case 'c':
           while (1) {
                close(dup(0));
                iter++;
           }
           /* NOTREACHED */
        case 'g':
           while (1) {
                getpid();
                iter++;
           }
           /* NOTREACHED */
           ...
        }
        ...

syscallテストプログラムでは第2引数でテストの種類を指定することができ、それが上のコードサンプルのswitch(test[0])の行に対応しています。無指定の場合は"mix"が指定されたのと同じとなっていて、上記サンプルで言えば続くcase 'm':行以下のwhileループがそれに相当することになります。ループが1回回るたびにiter変数がインクリメントされるので、最終的にこのiterの値がいくつになったかがテスト結果となります。whileは見た目上永久ループになっていますが、SIGALRMによって抜け出すようになっています。テスト起動時の第1引数がテストの継続時間となっていて、これがalarm()に使われている訳です。

つまり、上記のコードサンプルからすると、close()/dup()/getpid()/getuid()/umask()の5つのシステムコール関数のいずれかがAMD/Intel両アーキテクチャ間での性能差を引き出していたことになるわけです。うーん。惜しむらくはここを気にする前にAthlon/Phenomとも手放してしまったことですが...。こちらを見る限り、これはAthlon/Phenom共々出ている傾向のようなんですよね。

Hironobu Koura (15:46) | コメント(0) | トラックバック(0)

2010年4月27日

PC内温度を監視するよ

OCなんてCPUを早くダメにするだけだと思ってる(本当の所は知らないが)くらいなので、今までPC組むのに冷却なんてほとんど考えてなくて、というか考えるような攻めの構成はほとんどやったことがない。ので、今回Phenom II X4の965BEは爆熱だよなんて話を聞いてちょっと青ざめたのは確かだ。

というか、冷却のためのCPUクーラーがえらいうるさい。リテールクーラーの悪評は紛々たるものらしく、ちょっとぐぐっただけでもブログ記事とか実証動画だとかがアホの子のごとく出てくる。

で、気になって色々と調べてみた。いずれもdebian lenny(kernel: 2.6.26.2)。

まずAMD組、lm-sensorsをつっこもうとしたら、AMD系ではそのままでは温度が取得できないらしい。k10tempというのを持って来てmake & install。すると1ヶ所しか取れないのは何だろう。CPU温度かな。

http://khali.linux-fr.org/devel/misc/k10temp/
Index of /devel/misc/k10temp 

# aptitude install linux-headers-2.6.26-2-amd64 (←/lib/modules/2.6.26.2-amd64/buildを見るので)
# mkdir k10temp
# cd k10temp
# wget http://khali.linux-fr.org/devel/misc/k10temp/Makefile
# wget http://khali.linux-fr.org/devel/misc/k10temp/k10temp.c
# make 
# make install
# depmod -a (←make installの途中でdepmodのところでミスるので手でやりなおした)

hironobu@emma:~$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
temp1:       +38.1°C  (high = +70.0°C, crit = +72.0°C)

Atom組の方も見てみると、こちらはlm-sensorsのインストールのみですぐ出て来たものの、M/B温度が70度近くとか言っちゃってこっちもこっちで結構な数字が出ているじゃないか。まあファンレスだから仕方ないんだと思うけども。 

hironobu@shirley:~$ sensors
w83627thf-isa-0290
Adapter: ISA adapter
VCore:       +1.15 V  (min =  +0.00 V, max =  +3.84 V)   
+12V:        +3.83 V  (min = +15.44 V, max =  +2.37 V)   ALARM
+3.3V:       +1.89 V  (min =  +1.87 V, max =  +3.10 V)   
+5V:         +4.91 V  (min =  +1.25 V, max =  +2.56 V)   ALARM
-12V:        +2.03 V  (min =  +6.06 V, max =  -2.74 V)   ALARM
V5SB:        +4.95 V  (min =  +2.34 V, max =  +2.96 V)   ALARM
VBat:        +3.23 V  (min =  +2.91 V, max =  +2.00 V)   ALARM
fan1:          0 RPM  (min =  827 RPM, div = 8)  ALARM
CPU Fan:       0 RPM  (min = 2343 RPM, div = 4)  ALARM
fan3:          0 RPM  (min = 6026 RPM, div = 2)  ALARM
M/B Temp:    +67.0°C  (high = -33.0°C, hyst = +32.0°C)  ALARM  sensor = thermistor
CPU Temp:    +53.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = diode
temp3:       +53.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = diode
beep_enable:enabled

Hironobu Koura (15:03) | コメント(1) | トラックバック(0)

2010年4月22日

Knoppixを起動するUSBメモリを作ろう。

さて、旧サーバ(old shirley)を退役させるためにHDDを掃除しなきゃいけないわけですが、以前はUSBフロッピードライブをもってきてDESTROYとかやってたんですけど、先日から探してるのに肝心のドライブが出てこない(何)。そんなわけで、Knoppixを使ってUSBメモリにブートイメージをつっこんでshredすることに。

というわけで皆様材料はこちらになります。鶏肉に卵と玉ねぎ、お醤油みりん砂糖...あれ。

  • USBメモリ (容量1GBもあればOK、FATでフォーマット済みの)
  • KnoppixのISOイメージ(最新)
  • SYSLINUX(最新)
  • Linux PC 1台

ぐぐると結構皆さんCD-Rを使って焼いたりとかそうでなくてもDaemontoolsを持って来たりとかやってますが、WindowsでなくてLinuxでやれば、それらと同じ作業はすべて標準で入ってるので、格段に簡単にできます。っていうか、本当は簡単にできるはずなんだけどついつい手順を忘れて何となくめんどくさがりがち...。全然むずかしいこっちゃないですよと、備忘録として記して忘れないようにしておくのでござるよ。

http://www.knopper.net/knoppix-mirrors/
KNOPPIX - Mirrors

Knoppixはこのミラーリストからダウンロード。日本語サイトがなんかやたら古かったりデッドリンクばかりと不安な空気を醸し出しているので、そちらは振り切って本家サイトに逝くでござるよ。

http://www.kernel.org/pub/linux/utils/boot/syslinux/
Index of /pub/linux/utils/boot/syslinux

SYSLINUXも同じく最新を。tar+gzでもtar+bz2でもzipでもどれでもござれ。であとは下のように1)USBメモリをマウント、2)KnoppixのISOもマウント、3)Knoppixの内容物(/boot/isolinux/*,/KNOPPIX)をUSBメモリにコピー、4)USBメモリ内にコピーした/isolinux.cfgを/syslinux.cfgにリネーム、5)SYSLINUXをUSBメモリにインストール、で完了。 

~# mkdir ./tmp
~# mount -o loop ./KNOPPIX_V6.2CD-2009-11-18-EN.iso ./tmp
~# mount /dev/sdb /mnt
~# cp -pr ./tmp/boot/isolinux/* /mnt/
~# cp -pr ./tmp/KNOPPIX /mnt/
~# cd /mnt
~# mv isolinux.cfg syslinux.cfg
~# ~/syslinux-3.86/linux/syslinux /dev/sdb
(※USBメモリを/dev/sdb、またisoとsyslinuxのtarballをrootのホームディレクトリに置いて解凍したとして仮定。)

あとはKnoppixのisoイメージ(~/tmp)とUSBメモリ(/mnt)をアンマウントして、目的のPCにUSBメモリを刺して起動すればいいだよ。

Hironobu Koura (16:41) | コメント(0) | トラックバック(0)

2010年4月21日

Receive-Side Scalingとな？

(11:48訂正、shirley(M/B:D510MO/NIC:Realtek8111DL)だと無手順でばらけました。)

前のエントリで書いたApache Benchの件は、ちと早計というか、違う問題のようだということが分かって来た。あのあとぐぐってみると、気になる記事を見つけたの。

http://blog.nomadscafe.jp/2010/01/cpu.html
アプリケーションがマルチスレッドでもマルチコアCPUを活かせない件 - blog.nomadscafe.jp

memcachedの通信は主にeth1で行われるのですが、このeth1に関する割り込み処理がCPU1でしか行われていません。ソフトウェア割り込みはハードウェア割り込みが行われたCPUでしか行われないのもこの傾向を強めます。

マルチコアCPUの性能を活かすために考えられることは、ネットワークの割り込み処理を複数のCPUに分散することだと思うのですが、最新のNICにはRX/TX Multiple Queue(正式名称がわからない。Receive Side ScalingとかScalable I/O？)機能が備わっています。もともとRX/TX Multiple Queueは10GbpsのNICなどに備わっていた機能で、複数の割り込みチャンネルを持つことでネットワーク処理の分散を実現しています。最近のIntelやBroadcomの1GbpsのNICにも同じ機能があります。 

emma:~# cat /proc/interrupts 
            CPU0       CPU1       CPU2       CPU3       
   0:         45          0          6          0   IO-APIC-edge      timer
   1:          0          0          8          0   IO-APIC-edge      i8042
   6:          1          0          2          0   IO-APIC-edge      floppy
   7:          0          0          0          0   IO-APIC-edge      parport0
   8:          0          0          1          0   IO-APIC-edge      rtc0
   9:          0          0          0          0   IO-APIC-fasteoi   acpi
  14:          0          0          0          0   IO-APIC-edge      ide0
  15:          0          0          0          0   IO-APIC-edge      ide1
  16:          0          0        236          0   IO-APIC-fasteoi   ohci_hcd:usb1, ohci_hcd:usb3, hda_intel
  17:          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb2
  18:          0          0          0          0   IO-APIC-fasteoi   ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
  19:          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb4
  22:          0          0       2002          2   IO-APIC-fasteoi   ohci1394, ahci
  25:          0          0       3150          0   PCI-MSI-edge      eth0
  26:          0          0          0          0   PCI-MSI-edge      hda_intel
 NMI:          0          0          0          0   Non-maskable interrupts
 LOC:       8113      12668       9084       7116   Local timer interrupts
 SPU:          0          0          0          0   Spurious interrupts
 PMI:          0          0          0          0   Performance monitoring interrupts
 PND:          0          0          0          0   Performance pending work
 RES:       3646       3930       2110       2260   Rescheduling interrupts
 CAL:         42        124        135        122   Function call interrupts
 TLB:          4          0          3          7   TLB shootdowns
 TRM:          0          0          0          0   Thermal event interrupts
 THR:          0          0          0          0   Threshold APIC interrupts
 MCE:          0          0          0          0   Machine check exceptions
 MCP:          6          6          6          6   Machine check polls
 ERR:          4
 MIS:          0

確かにこのページで語られてるのと同じ状況。mary,emmaでも同じだった。httpdを入れてないので確認してないけど、/proc/interruptsを見る限りnellyでも同じっぽい。shirleyではばらけたぞ。

うちのマシンは揃ってRealTek製の8111C(shirleyだけ8111DL)のチップだったのだけど、これらは"Receive-Side Scaling"の機能であれば対応しているらしい。

http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=5&Level=5&Conn=4&ProdID=142
Realtek (8111C)

http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&ProdID=193
Realtek (8111DL)

これがLinux上でどう対応づけすればいいのか調べ中でござる...。

Hironobu Koura (02:03) | コメント(0) | トラックバック(0)

2010年4月 6日

routerをSRT100からLinux PCサーバに入れ替えたよ

一通り設定が終わったのでリプレース、多少てこずったというかひさびさのケーブリングで戸惑ったりしたけど何とか無事に完了。distroはdebian(lenny)で、スペックはAtom 330(Intel D945GCLF2)にメモリ2GBのSSD 40GB(これもIntel)。NICも2枚差し(正確には内1個オンボード)なんて何年振りだろ。多少まごついたけどおさだまりのip_forwardとiptablesでNAT(今回の場合はMASQUERADE)とフレッツ用のpppoeと、そのくらいでだいたい行けた。もちろん(？)kernelソースも持って来てはありますが、まだ使いどころが無かった。

一緒にOCN IPv6サービスも申し込んだので、こちらの設定も追々する予定。ああ、不要なdebパッケージをお掃除したいね。

Hironobu Koura (23:16) | コメント(0) | トラックバック(0)

メインページ | アーカイブ | mac »