なんで俺のメールは無視されてるんだよーとの苦情に答えて

On Sat, 26 Apr 2008, Adrian Bunk wrote:
>
> Linus takes patches from people like Andrew, Al and Harvey directly,
> but he doesn't take the same patches directly from me.

It's because I hate you.

Oh, no, wait.

It's because you didn't send the patch to me.

Linus

ギャグを言わないと気がすまない所は誰かを彷彿とさせるな。

絶賛もだえ苦しみ中

LKMLで絶賛開催中。
空気読まずに適当にコメントしたら、なぜかLTTngがマージされたりした。
もうカオスとしかいいようがない。

http://ossmpedia.org/messages/linux/2.6.9-34.EL/482.ja

　物理ページの確保に失敗した。要求したサイズと確保時に指定した空きページの探索方法を表示する。

　物理メモリが不足している場合に発生する。また，空きメモリが充分であっても，物理メモリが断片化し要求サイズ分の物理ページが連続して確保できない場合は発生する。

うーむ、この説明だと普通のときは出ないメッセージであるかのように書いてあるが、んなこたーない。
ネットワーク系のドライバだとパケット受け取った時に、そのデータを格納する用のメモリ確保を行うことが多いのだが、そのときに使われる関数 netdev_alloc_skb() は　__GFP_NOWARN を立てない。

かつ、Linuxはメモリ管理哲学としてぎりぎりまでメモリを開放せずにキャッシュとして使い続け、メモリ確保要求が来てから開放する仕組みをとっているが、割り込みの延長からはロックの都合上この開放処理がおこなえないので、通常よりかなり高い確率でメモリ確保は失敗する。

なので、ある種のネットワークカード（特にe1000とtg3)は高負荷時にしばしばpage allocation failureのメッセージを出すが、これは高負荷だったので、パケット１つ捨てたよーーん。という意味でしかなく、どうせ流れてるのはTCP/IPだろうからACKしなきゃ再送してくるっしょ。という意味であり、特に対処は必要ない。

先日Andrew Mortonがe1000にだけスペシャルなハックいれてワーニングを回避しようとしていたので、tg3で起きるよーん。ジェネリックなレイヤで直そうぜーというメールを書いてみたのだが、Dave Millerのお気にめさなかったらしく、物理連続なメモリを要求するハードなんて腐ってるぜー、そんなもののために対応したくないぜー。と却下されてしまった。

＃ 加えて、古いLinuxのドライバはエラー対応が腐ってるドライバが多いので
＃ デフォルトをNOWARNにするのはありえないらしい

よって、この問題は技術的な問題ではないので、直る見込みがない。
e1000ユーザは枕を涙で濡らしてください。

＃あ、TG3はIOMMUがあるのにドライバが使ってないだけなので、ドライバメンテナが
＃ドライバ書き直す宣言をしているので、将来的に直るらしい


BTW：　ところで、メッセージペディアの書き込み権限ってどうやったら手に入るのかいね？
こういうの気になるんだけど

http://journal.mycom.co.jp/news/2008/04/18/007/index.html

プロセス管理機構も見直され、プロセスごとのメモリ使用量をかんたんに測定できる機能が追加された。カーネル2.6.25では、プロセスが使用するページに対応する物理ページ配置をプロセスごとに/proc/$PID/pagemapsとして作成、これを他のプロセスと比較することで共有するページを判別できる。共有ページを共有しているプロセスの数で除した数値を持つ「proportional set size (PSS)」と、共有されていないページをカウントした「unique set size (USS)」という2つの統計値も新設された。

この説明はへんだ。
カーネル内にUSSという統計値は存在しない。また、pagemapsというファイルは存在しない（pagemapだ）

pagemapはページのPFNが知りたいときしかほぼ使い道はなくて、
ページ共有されているかどうか。およびUSS、PSSは/proc/$PID/smaps　を見る

36c5400000-36c554a000 r-xp 00000000 08:01 18940074 /lib64/libc-2.5.so
Size: 1320 kB
Rss: 508 kB
Pss: 28 kB
Shared_Clean: 508 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 508 kB
Swap: 0 kB

ここで、
・共有されているものはSharedにカウントされる
・専有されているものはPrivateにカウントされる
・PssはRssを共有数で割ったもの

という規則によりプロセス全体のRSS、PSS、USSは
RSS:　アドレス空間毎のRssを合算
PSS:　アドレス空間毎のPssを合算
USS:　アドレス空間毎のPrivate_Clean + Private_Dirty を合算

で計算できる事になります。
実はpagemapはかなりUI 設計ミスでpte holeもPFN not presentなページをひたすら返すので
64bitアーキで

$ cat /proc/$$/pagemap > pagemap.txt

とかやると、ひどい事になります。さすが組み込み向け。


BTW:　ソース見てて気づいたがHugepageの配慮が抜けてるぞー > pagemap

携帯版でＤＱ２クリアした。
なんというか、バランス調整がされていて、これは僕が知っているＤＱ２じゃないというか。。

魔法が普通に役に立つとか、サマルトリア王子が普通に使えるとか違和感がたっぷり。とか
あと、この時代は船を入手したらもう終盤だったんだなー。とかとか

まあ、いろいろと感慨深かった。

今日はこんぴゅーたが使えない日という事もあって会社を休んだ。
めどいのでおうちでごろごろしていようかとも思ったが、気分を変えてＧｏｏｇｌｅ Developer交流会に行ってきた。テーマのＡｎｄｒｏｉｄにちょっと興味あったし

結論から言うと大はずれ。濃ゆい話が出来る開発者が一人も来とらんやんけ。
交流会名乗るからには、実開発者呼んで来い。広報担当者とかマジいらない

Leeのパッチをデバッグしていて、つくづく思ったがLinuxのanonなリバースマップのデータ構造は素直じゃないね。

CodeFestが知らないうちに終わっていた。
こんなんばっかりなので、FSIJに入会したいと思っているのだがずいぶん前から、募集打ち切ってるんだよな

http://www.fsij.org/homepage/

なんか最近やけに、うちのブログの検索ワード履歴でjemalloc をみかけると思ったらFirefox3に採用されたんだそーな。
んじゃ、こんどなんか記事かこうかしらね

git の記事が載っているというのでがんばって、Amazonさんから取り寄せたのに、ほとんどのページはFreeBSDな話題だった。しょぼーん

備忘録
libmemusageを使うと以下のように、どのようなメモリの使い方をしているのかをヒストグラムで表示してくれる。

$ LD_PRELOAD=libmemusage.so ls
bin   etc     kdump  lib64       misc  opt   sbin     sys       usex-tmp  work
boot  home    kexec  lost+found  mnt   proc  selinux  tftpboot  usr
dev   initrd  lib    media       net   root  srv      tmp       var

Memory usage summary: heap total: 47175, heap peak: 30979, stack peak: 11632
         total calls   total memory   failed calls
 malloc|        135          46455              0
realloc|          7            720              0  (nomove:6, dec:6, free:0)
 calloc|          0              0              0
   free|         26          16887
Histogram for block sizes:
    0-15             46  32% ==================================================
   16-31              5   3% =====
   32-47             38  26% =========================================
   48-63              9   6% =========
   80-95              2   1% ==
   96-111            22  15% =======================
  112-127             4   2% ====
  160-175             1  <1% =
  192-207             1  <1% =
  208-223             1  <1% =
  432-447             2   1% ==
  560-575             3   2% ===
  720-735             1  <1% =
  816-831             1  <1% =
  944-959             1  <1% =
 3712-3727            1  <1% =
 4096-4111            1  <1% =
 4144-4159            1  <1% =
 5376-5391            1  <1% =
19200-19215           1  <1% =

タイトルオンリー。

なんでオイラのパッチは放置されてんのん？って聞いたらかくの如き答え。
おいおい、あんたが見てなかったらあのML、存在意義ないぞ（＾＾；；

LKMLのマナーとして投稿前にcheckpatch.pl にかける。っちゅーのがあるんだけど、
quiltを使っているとパッチ名なんかおぼえちゃいないので、すぐ忘れる。

とゆーわけで、checkpatchをquiltに統合してみた。


以下のスクリプトを /usr/local/share/quilt に実行権限付きで配置すると
$ quilt checkpatch

でquilt上でtopに配置されているパッチに対してcheckpatch出来ます。
５分でつくったので、バグがあるかもしれませんが、そこそこ使えます。

つか ガッ となってやった。反省はしていない

#! /bin/bash

# Read in library functions
if [ "$(type -t patch_file_name)" != function ]
then
        if ! [ -r $QUILT_DIR/scripts/patchfns ]
        then
                echo "Cannot read library $QUILT_DIR/scripts/patchfns" >&2
                exit 1
        fi
        . $QUILT_DIR/scripts/patchfns
fi

top=$(find_top_patch) || exit 2
./scripts/checkpatch.pl patches/$top

### Local Variables:
### mode: shell-script
### End:
# vim:filetype=sh

４／１ですね。


技術者として食っていくのに見切りをつけ、ライターになる決意を固めました。
現在いくつかの編集者と打ち合わせをしつつ、話を前に転がすべく鋭意奮闘中です