を、わざわざ取り寄せて買ってしまったぜ。主題歌聞きたくなって。
たしかリメイク版は主題歌が変わってしまっていて、しかも、いけてないんだよな

なんかGoogleノートブックを利用したスパムトラックバックが鬼のようにくる。
ふだんはメリケンスパムは「全部英語のトラックバックはスパムとみなす」規則によって、はじいているのだが、ぐぐるがかむと、Googleノートブックが勝手に日本語の免責事項文章を入れるせいでこの規則を逃れてしまう。
うががが、腹たつーー

vmstat 1 などとして、定期的表示を実行させていると、まれに

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa

 1  0     99     42     25     62    0    0     0     0 2031   58  0 13 88  0

 2  1     99     14     21     61    0    0   219     0 2034  123  0 21 79  1

 1  0     99     37     20     61    0    0 4294967275     0 2016   53  0 20 78  2

 5  0     99     16     15     55    0    0   201     0 2042  133  0 34 65  1

 2  0    101     31     11     50    0    0     0     0 2039   82  0 39 60  1

 4  1    108      8      6     46    0    0   298     0 2123  273  0 42 57  1

3656  1    120    460      2     35    0    0   285  6976 2176  685  0 61 35  4

 0  0    102   4836      2     27    0    0     0   448 2038 3789  0 49 51  0

 0  0    102   4838      3     26    0    0     0    40 2032   71  0  0 99  1

のようにbi 欄がトンデモな値になることがある。
１秒前の値よりも小さな値が/proc/vmstatにて取得されるので、unsignd での減算が発狂してしまうのだ。
hackbenchとか流そうもんなら頻出。

んで、今日一日追ってみたのだけれど、原因がまったく分からず。
とほほ・・・

分かった事

・vmstat コマンドにアミを仕込んだ結果 /proc/vmstatの取得結果が前回よりも減る事があるのが
　確認できた。
つまり、vmstatコマンドのバグではない
・カーネルにアミを仕込んだ結果、カーネル内でカウンタを減算する処理は一切走っていない事が分かった
・んじゃ、メモリオーダかなと他人のCPUのcpu varを読む処理を全部削除（てか、こんなんある時点で現在のコードはあきらかに間違ってる気がするんだけど・・・）しても結果は変わらず

むかついたので、もう寝るザマスよーー


追記：　原因判明。
　　　　　2.6.25-mm1は/proc/vmstatが壊れており、カラムが途中から全部１行ずれとる。
　　　　　よって、pgpgin に表示されているのはNUMAヒット率なので、減ってしまっても
おかしくないという。。。。
　　　　　バカか！

　　　　　教訓：　人間ソースコードがおかしいとすぐ気づくが文字列の配列が途中で一行抜けていてもなかなか気づかない。
　　　　　教訓２：　人間、偏見をもってみると全然関係ない統計値でも、すこしも疑問に思わずだまされる。

って一杯ありすぎてさっぱり分からん。
以下で質問してみた

http://q.hatena.ne.jp/1209801037

mem_notifyの改善に必要なんじゃよー

死ぬほどバグが残っている先週は怒りくるっていたのだが、がつんがつんパッチをマージさせていき、やっとこさ全てのテストが通ったよ。

お次はAndrewの攻略が控えてるんだよなぁ・・・
ちょっと滅入る