とおもったら、とっくの昔にlinux-mmにパッチでてた。
しかし、i386が動かなくなるようなパッチを投げる気がしれんな。
とりあえず、mem_notify v4の作業はすべて完了。
来週頭ぐらいに一度なげるべ。
しかし、i386が動かなくなるようなパッチを投げる気がしれんな。
とりあえず、mem_notify v4の作業はすべて完了。
来週頭ぐらいに一度なげるべ。
January 2008
McAfeeがGPLに対するFUDを行ったという話
matz日記より
http://www.rubyist.net/~matz/20080108.html#p03
うーん、そうは思わなかったりする。
投資家向けの年次報告書は、株価が落ちたときにそのリスクが前年度の報告書に書いてないと、だましたなー扱いで訴えられて泣きっ面に蜂というか一粒で二度おいしいというか、そういう痛い状況になってしまうので悪い方向に過敏に書くのは、あっちの世界ではむしろ良心的行動。
Windowsが没落することにより株価下落の可能性があるのは事実なんだし。
むしろannual reportの内容を空気読まずにギークに転載しちゃうのがよくねーと思うだわよ。別にプレスリリースとかで語ったわけじゃないんでしょ。
違う世界の文化も受け入れてあげるべきだと思うな
とか思ったり、思わなかったり。
駄文。。。
http://www.rubyist.net/~matz/20080108.html#p03
McAfee throws some FUD at the GPL - The INQUIRER
McAfeeがGPLに対するFUDを行ったという話。
In its annual report, Windows security software vendor McAfee told its investors that open source software licence terms it vaguely characterised as " ambiguous" might "result in unanticipated obligations regarding our products."
投資家に対する年次報告においてMcAfeeは以下のように報告した。「オープンソースソフトウェアの曖昧な性質によって、我々のプロダクトに予期しない義務が発生する可能性がある」
"To the extent that we use 'open source' software, we face risks," McAfee stated.
「オープンソースソフトウェアの利用によって、我々はリスクに直面している」
裏は取っていないけど、これが真実であるとしたら、かなりひどい話。
うーん、そうは思わなかったりする。
投資家向けの年次報告書は、株価が落ちたときにそのリスクが前年度の報告書に書いてないと、だましたなー扱いで訴えられて泣きっ面に蜂というか一粒で二度おいしいというか、そういう痛い状況になってしまうので悪い方向に過敏に書くのは、あっちの世界ではむしろ良心的行動。
Windowsが没落することにより株価下落の可能性があるのは事実なんだし。
むしろannual reportの内容を空気読まずにギークに転載しちゃうのがよくねーと思うだわよ。別にプレスリリースとかで語ったわけじゃないんでしょ。
違う世界の文化も受け入れてあげるべきだと思うな
とか思ったり、思わなかったり。
駄文。。。
いまごろ年賀状とどいた
って、もう８日やぞ！
いくら引越しして転送されてるからって遅すぎないか？！
＃１０枚ぐらいいっきに来たので、差出人のみなさんは１／１に届くようにしていたと思われる
いまから返事を書いても時期はずれだしなー。どうしようかなー
それをいいわけにして返事をさぼるかー
いくら引越しして転送されてるからって遅すぎないか？！
＃１０枚ぐらいいっきに来たので、差出人のみなさんは１／１に届くようにしていたと思われる
いまから返事を書いても時期はずれだしなー。どうしようかなー
それをいいわけにして返事をさぼるかー
spamコメントむかつく
最近IEの新しい脆弱性が発見されたようでスパムコメントが活発化している。
エロサイト誘導とかは特に実害ないので放置を基本にしているが、さすがにクラッシュやらHDDフォーマットやらを仕込まれると人様に迷惑がかかるので、消したくなる。
んでイタチゴッコ ←いまここ
はげしくメドイ
なんかいいフィルター方法ないかしらね
エロサイト誘導とかは特に実害ないので放置を基本にしているが、さすがにクラッシュやらHDDフォーマットやらを仕込まれると人様に迷惑がかかるので、消したくなる。
んでイタチゴッコ ←いまここ
はげしくメドイ
なんかいいフィルター方法ないかしらね
実態を糊塗して成果を大きく見せる方法
kzk benchの高速化についてまったくやる気がおきなくて、今日はだらだらすごしてしまった。
んで、最近佐藤優の一連の著作を読みまくったのでインテリジェンス業界のやり口がすこし分かってきたので、自分のやる気に対して応用してみるテスト。
成果が５％。と書くとまるでダメな子みたいであるが、ここで視点を変えてみよう。
うちのマシンにおいてはディスクI/O性能がだいたい20MB/sであることが経験則で分かっている。なので、1(GB)/20(MB/s)=50sがソフトネックがなく、ディスクシークも発生しなかった時の速度。
だから、58.17s -> 55.03s というのはオーバヘッドが8.17 -> 5.03という見方もできる！
つまり
,.ｨ , - ､.＿ 、
. ,ｲ/ l/ ￣￣｀ヽ!__
ﾄ/ |' { ｀ヽ. ,ﾍ
Ｎ│ ヽ. ` ヽ /ヽ / ∨
N.ヽ.ヽ、 , } l＼/ `′
. ヽヽ.＼ ,.ｨｲﾊ | ＿|
ヾニｰ __ _ -=_彡ｿﾉ u_＼ヽ、 | ＼ 実は＋４０％の
. ￣ﾞr=<‐ﾓﾐ､ﾆr;＝=ｪ;ｭ＜_ゞ-=7´ヽ > 高速化に成功して
. l ￣ﾘーh ｀ ｰ‐‐' l‐''´冫)'./ ∠__ いたんだよ！！
ﾞiｰ- ｲ'__ ヽ､..＿__ノ ﾄr‐' /
l `＿__,.、 u ./│ /＿
. ヽ. }z‐r--| ／ ﾄ, | ,、
>､`ｰ-- ' .／ ／ |ヽ l／ ヽ ,ﾍ
_,.／| ヽ`ｰ--‐ _´.. ‐''´ ./ ＼､ ＼/ ヽ/
-‐ '''" ￣ / :| ,ゝ=＜ / | `'''‐- ､.._
/ !.／l;';';';';';';＼ ./ │ ＿
_,＞ '´|l. ﾐ:ゝ､;';';_/,´＼ ./|._ , --､ | i´!⌒!l r:,＝i
. | |:.l. /';';';';';|= ヽ/:.| .|l⌒ｌ ｌﾆ._ | ﾞｰ=':| |. L._｣ ））
l. |:.:.l./';';';';';';'! /:.:.| i´|.ｰ‐' | / | |. ! l
. l. |:.:.:.!';';';';';';';'| /:.:.:.:!.|"'|. l' │-==:|. ! ==l ,. -‐;
l |:.:.:.:l;';';';';';';';| /:.:.:.:.:| i＝!ｰ=;: l | l. | | / //
l |:.:.:.:.:l;';';';';';';'|/:.:.:.:.:.:.!│ l l、 :| | } ＿|,.{:: 7 ））
l |:.:.:.:.:.:l;';';';';'/:.:.:.:.:.:.:.:| |__,.ヽ､__,. ヽ._｣ ｰ=:::ﾚ' ::::::|; 7
. l |:.:.:.:.:.:.l;';';'/:.:.:.:.:.:.:.:.:.|. ＼:::::＼::::: ヽ ::::::!′ :::| .:/
. ｌ |:.:.:.:.:.:.:∨:.:.:.:.:.:.:.:.:.:.:.! /ヽ::: `::: :::: ....::....／
・・・・だめだ
無理がありすぎる。
やる気をだすなんて無理。
んで、最近佐藤優の一連の著作を読みまくったのでインテリジェンス業界のやり口がすこし分かってきたので、自分のやる気に対して応用してみるテスト。
成果が５％。と書くとまるでダメな子みたいであるが、ここで視点を変えてみよう。
うちのマシンにおいてはディスクI/O性能がだいたい20MB/sであることが経験則で分かっている。なので、1(GB)/20(MB/s)=50sがソフトネックがなく、ディスクシークも発生しなかった時の速度。
だから、58.17s -> 55.03s というのはオーバヘッドが8.17 -> 5.03という見方もできる！
つまり
,.ｨ , - ､.＿ 、
. ,ｲ/ l/ ￣￣｀ヽ!__
ﾄ/ |' { ｀ヽ. ,ﾍ
Ｎ│ ヽ. ` ヽ /ヽ / ∨
N.ヽ.ヽ、 , } l＼/ `′
. ヽヽ.＼ ,.ｨｲﾊ | ＿|
ヾニｰ __ _ -=_彡ｿﾉ u_＼ヽ、 | ＼ 実は＋４０％の
. ￣ﾞr=<‐ﾓﾐ､ﾆr;＝=ｪ;ｭ＜_ゞ-=7´ヽ > 高速化に成功して
. l ￣ﾘーh ｀ ｰ‐‐' l‐''´冫)'./ ∠__ いたんだよ！！
ﾞiｰ- ｲ'__ ヽ､..＿__ノ ﾄr‐' /
l `＿__,.、 u ./│ /＿
. ヽ. }z‐r--| ／ ﾄ, | ,、
>､`ｰ-- ' .／ ／ |ヽ l／ ヽ ,ﾍ
_,.／| ヽ`ｰ--‐ _´.. ‐''´ ./ ＼､ ＼/ ヽ/
-‐ '''" ￣ / :| ,ゝ=＜ / | `'''‐- ､.._
/ !.／l;';';';';';';＼ ./ │ ＿
_,＞ '´|l. ﾐ:ゝ､;';';_/,´＼ ./|._ , --､ | i´!⌒!l r:,＝i
. | |:.l. /';';';';';|= ヽ/:.| .|l⌒ｌ ｌﾆ._ | ﾞｰ=':| |. L._｣ ））
l. |:.:.l./';';';';';';'! /:.:.| i´|.ｰ‐' | / | |. ! l
. l. |:.:.:.!';';';';';';';'| /:.:.:.:!.|"'|. l' │-==:|. ! ==l ,. -‐;
l |:.:.:.:l;';';';';';';';| /:.:.:.:.:| i＝!ｰ=;: l | l. | | / //
l |:.:.:.:.:l;';';';';';';'|/:.:.:.:.:.:.!│ l l、 :| | } ＿|,.{:: 7 ））
l |:.:.:.:.:.:l;';';';';'/:.:.:.:.:.:.:.:| |__,.ヽ､__,. ヽ._｣ ｰ=:::ﾚ' ::::::|; 7
. l |:.:.:.:.:.:.l;';';'/:.:.:.:.:.:.:.:.:.|. ＼:::::＼::::: ヽ ::::::!′ :::| .:/
. ｌ |:.:.:.:.:.:.:∨:.:.:.:.:.:.:.:.:.:.:.! /ヽ::: `::: :::: ....::....／
・・・・だめだ
無理がありすぎる。
やる気をだすなんて無理。
marceloから返事来た
だめだ、こいつ分かってねー
/::::i::::､:::ヽ､:::::＼:ヽ:＼::::::ヽ:::､::ヽ::､:',
/::i|::l::ﾄ､ヽ::､:::ヽ:､::::::＼::ヽ::::l::::ヽ::i:::i:::!
/:/:!:::!:|::ヽ:＼ヽ::::､:＼::::ヽ:::ヽ!::::::i::|:::!::!
!ﾊ::|::::i::l:|心､:ヽ::＼:ヽ_＼､＼:::ヽ:::|!::|:|i
i､:!:|:､N{､ﾋjヽゝ＼ヾｲ ﾋｊ >､ヽi:､|!:|:l
ヽ:!::ﾄヽ￣ l! ` ｀￣´ |::l::|:|j:,!:! 駄目だこいつ
ﾄ､::! u ｊ |::/lj:::!ﾘ
ヾ、 丶 - u ﾘｲ:|ﾘ 早くなんとかしないと……
ﾘヽ ‐､ｰ- ､_ ／ｲ:::i
rｰ'"ﾄ:lﾞ､ ￣ .／ , |::!
/ ﾍ ヾ ヽ､ _,. ' / |:'
/::::i::::､:::ヽ､:::::＼:ヽ:＼::::::ヽ:::､::ヽ::､:',
/::i|::l::ﾄ､ヽ::､:::ヽ:､::::::＼::ヽ::::l::::ヽ::i:::i:::!
/:/:!:::!:|::ヽ:＼ヽ::::､:＼::::ヽ:::ヽ!::::::i::|:::!::!
!ﾊ::|::::i::l:|心､:ヽ::＼:ヽ_＼､＼:::ヽ:::|!::|:|i
i､:!:|:､N{､ﾋjヽゝ＼ヾｲ ﾋｊ >､ヽi:､|!:|:l
ヽ:!::ﾄヽ￣ l! ` ｀￣´ |::l::|:|j:,!:! 駄目だこいつ
ﾄ､::! u ｊ |::/lj:::!ﾘ
ヾ、 丶 - u ﾘｲ:|ﾘ 早くなんとかしないと……
ﾘヽ ‐､ｰ- ､_ ／ｲ:::i
rｰ'"ﾄ:lﾞ､ ￣ .／ , |::!
/ ﾍ ヾ ヽ､ _,. ' / |:'
最新Linuxでmm_mun_cpが実行できん
どうもメモリ管理が変わった拍子に
この定理に関して、私は真に驚くべき証明を見つけたが、この32bitアドレス空間はそれをmmapするには狭すぎる
と遺言されてしまっているらしい。南無
この定理に関して、私は真に驚くべき証明を見つけたが、この32bitアドレス空間はそれをmmapするには狭すぎる
と遺言されてしまっているらしい。南無
続々kzk benchが斬る
正月から何をやっているのか自分でも分かりませんがkzk bench解析のつづき。
ソースを読みながらつらつらと考えてみたところ、mw_madv_cpでは、どうやら以下のルートで処理が進んでいるようだと分かってきました
前提知識ですが、Linuxにおいてはページはactiveリストとinactiveリストという２本の
LRUリストで管理されています（/proc/meminfoでのactive, inactive欄ね）
なんで、二本あるのかというとページ回収するときに頻繁に参照されているページを
最初から除外できるとおいしいでしょ？ってぐらいに理解しておいてください。
名前から分かるようにinactiveなほうが、捨てられる（or スワップアウトされる）直前のページ群ね。
１．まずmmapedなメモリアクセスを契機にread aheadが走ります。
で、read aheadは読み込んだページをinactiveリストにつなぎます
２．memcpy君が実際にメモリに触ります。ここでPTEのaccess bitｔがONになります。
３．どこかのタイミングでメモリが足りなくなってページ回収が走ります
（おいらのマシンは５１２Mしかないので、オンメモリで１Gコピーは絶対ありえない）
４．ここでスワップアウトしようかなーとinactiveリストを舐めているときに、access bitが
立っていると、なんだ使ってるじゃんということでそのページはactive listに移されます。
今回のケースではなんと全ページactive list行き
５．でLinuxのメモリ管理のポリシーとしてmapped pageと普通のファイルキャッシュは
activeからinactiveへの転落しやすさが違います。
まあ、普通に考えてメモリとしてアクセスするページのほうがランダムアクセスされる
可能性は高いわけで、シーケンシャルアクセスの可能性が高いmmapされていない
普通のファイルキャッシュを先に捨てていくのは合理的といえなくもない。
６．で、memory pressureが十分高まるまではactive listに残ったreadメモリが
ぜんぜん捨てられないので、write用のメモリ領域がすくなくなってくる。
で、どうしようもなくなると、ある閾値を超えたところで一気にinactive listに
移動するので流れ作業が乱れまくり。と
実際iostatで見るとI/O転送レートがほんとうに上下しまくる
なので、４の段階でシーケンシャルアクセスだよん。とmadviseされていたら、
active listにいかない。というパッチをこさえてみました。
結果は以下。ようやっとrw_cp並。
約５％の性能向上やね。
ちなみに、あてたパッチは以下
が、しかし、このパッチは以下の致命的な欠点がある
・普通の人はmadviseなんか使わないので、明示的なヒントなしにシーケンシャルアクセスか
ランダムアクセスかを推測しないと本質的な解決にはならない。
（このパッチではmw_cpはぜんぜん高速化されていない）
なんだけど、mmapでそれを推測するのはめちゃくちゃ難しいぞ・・・
・そもそも、lock dependency的に行儀が悪いので、たまにデッドロックしてOSハングする
↑バカスｗｗｗ
今後のworkとしては
・mw_cpのmajor fault量からいってread aheadがうまく動いていないので動くようにする
・read aheadがうまくHITしているときはシーケンシャルアクセスとみなすようにする
の２段階で作業を進めればいいと思われる。
てか、本当になにをやっているんだか
なにをやってるの？ ランキング！
ソースを読みながらつらつらと考えてみたところ、mw_madv_cpでは、どうやら以下のルートで処理が進んでいるようだと分かってきました
前提知識ですが、Linuxにおいてはページはactiveリストとinactiveリストという２本の
LRUリストで管理されています（/proc/meminfoでのactive, inactive欄ね）
なんで、二本あるのかというとページ回収するときに頻繁に参照されているページを
最初から除外できるとおいしいでしょ？ってぐらいに理解しておいてください。
名前から分かるようにinactiveなほうが、捨てられる（or スワップアウトされる）直前のページ群ね。
１．まずmmapedなメモリアクセスを契機にread aheadが走ります。
で、read aheadは読み込んだページをinactiveリストにつなぎます
２．memcpy君が実際にメモリに触ります。ここでPTEのaccess bitｔがONになります。
３．どこかのタイミングでメモリが足りなくなってページ回収が走ります
（おいらのマシンは５１２Mしかないので、オンメモリで１Gコピーは絶対ありえない）
４．ここでスワップアウトしようかなーとinactiveリストを舐めているときに、access bitが
立っていると、なんだ使ってるじゃんということでそのページはactive listに移されます。
今回のケースではなんと全ページactive list行き
５．でLinuxのメモリ管理のポリシーとしてmapped pageと普通のファイルキャッシュは
activeからinactiveへの転落しやすさが違います。
まあ、普通に考えてメモリとしてアクセスするページのほうがランダムアクセスされる
可能性は高いわけで、シーケンシャルアクセスの可能性が高いmmapされていない
普通のファイルキャッシュを先に捨てていくのは合理的といえなくもない。
６．で、memory pressureが十分高まるまではactive listに残ったreadメモリが
ぜんぜん捨てられないので、write用のメモリ領域がすくなくなってくる。
で、どうしようもなくなると、ある閾値を超えたところで一気にinactive listに
移動するので流れ作業が乱れまくり。と
実際iostatで見るとI/O転送レートがほんとうに上下しまくる
なので、４の段階でシーケンシャルアクセスだよん。とmadviseされていたら、
active listにいかない。というパッチをこさえてみました。
結果は以下。ようやっとrw_cp並。
約５％の性能向上やね。
+(eval):1> sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+./test.sh:10> time ./rw_cp testfile1G testfile1G2
0.04user 4.40system 0:55.81elapsed 7%CPU (0avgtext+0avgdata 0maxresident)k
2099512inputs+2097152outputs (0major+91minor)pagefaults 0swaps
+(eval):1> sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
+./test.sh:17> time ./mw_madv_cp testfile1G testfile1G2
0.00user 5.11system 0:55.03elapsed 9%CPU (0avgtext+0avgdata 0maxresident)k
2099368inputs+2097152outputs (1major+262233minor)pagefaults 0swaps
ちなみに、あてたパッチは以下
---
mm/vmscan.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
Index: linux-2.6.24-rc6-cp2/mm/vmscan.c
===================================================================
--- linux-2.6.24-rc6-cp2.orig/mm/vmscan.c 2008-01-03 02:05:11.000000000 +0900
+++ linux-2.6.24-rc6-cp2/mm/vmscan.c 2008-01-03 02:25:39.000000000 +0900
@@ -435,6 +435,30 @@ cannot_free:
return 0;
}
+static bool page_sequential_mapped(struct page *page)
+{
+ struct address_space *mapping = page->mapping;
+ pgoff_t pgoff = page->index << (PAGE_CACHE_SHIFT - PAGE_SHIFT);
+ struct vm_area_struct *vma;
+ struct prio_tree_iter iter;
+ bool ret = true;
+
+ if (!page_mapped(page))
+ return false;
+
+ spin_lock(&mapping->i_mmap_lock);
+ vma_prio_tree_foreach(vma, &iter, &mapping->i_mmap, pgoff, pgoff) {
+ if (!VM_SequentialReadHint(vma)) {
+ ret = false;
+ break;
+ }
+ }
+ spin_unlock(&mapping->i_mmap_lock);
+ return ret;
+}
+
+
+
/*
* shrink_page_list() returns the number of reclaimed pages
*/
@@ -496,7 +520,8 @@ static unsigned long shrink_page_list(st
referenced = page_referenced(page, 1);
/* In active use or really unfreeable? Activate it. */
if (sc->order <= PAGE_ALLOC_COSTLY_ORDER &&
- referenced && page_mapping_inuse(page))
+ referenced && page_mapping_inuse(page) &&
+ !page_sequential_mapped(page))
goto activate_locked;
#ifdef CONFIG_SWAP
が、しかし、このパッチは以下の致命的な欠点がある
・普通の人はmadviseなんか使わないので、明示的なヒントなしにシーケンシャルアクセスか
ランダムアクセスかを推測しないと本質的な解決にはならない。
（このパッチではmw_cpはぜんぜん高速化されていない）
なんだけど、mmapでそれを推測するのはめちゃくちゃ難しいぞ・・・
・そもそも、lock dependency的に行儀が悪いので、たまにデッドロックしてOSハングする
↑バカスｗｗｗ
今後のworkとしては
・mw_cpのmajor fault量からいってread aheadがうまく動いていないので動くようにする
・read aheadがうまくHITしているときはシーケンシャルアクセスとみなすようにする
の２段階で作業を進めればいいと思われる。
てか、本当になにをやっているんだか
なにをやってるの？ ランキング！
kzk benchつづき
欝展開というやつですね。
改造しやすいようにと、最新カーネルビルドして再テストしたらめっさ速いんでやんの。
やる気なくすわー
2.6.24-rc6での結果は以下
相変わらず最速値はふつうのread-writeでのコピーですが、このぐらいだとほかの方法でもぜんぜん許せる気がします
mmap-mmapコピーの高速化（約２倍）もすごいし、madviseかけたときのページフォルトの数が約１／１０００になっています。
高負荷時に効きそうですね。
・・・
・・・・・・
・・・・・・・・・・・・
さて、次のネタをさがすか
憂鬱！ ランキング！
改造しやすいようにと、最新カーネルビルドして再テストしたらめっさ速いんでやんの。
やる気なくすわー
2.6.24-rc6での結果は以下
[kosaki@sc420 copy]$ ./test.sh
+./test.sh:10> time ./rw_cp testfile1G testfile1G2
0.06user 4.70system 0:56.17elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
2099456inputs+2097152outputs (0major+106minor)pagefaults 0swaps
+./test.sh:12> time ./rw_fadv_cp testfile1G testfile1G2
0.04user 4.54system 0:53.10elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
2099448inputs+2097152outputs (0major+107minor)pagefaults 0swaps
+./test.sh:14> time ./mm_sync_cp testfile1G testfile1G2
0.46user 3.52system 1:07.61elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
2099904inputs+2097160outputs (32772major+491656minor)pagefaults 0swaps
+./test.sh:16> time ./mm_mun_cp testfile1G testfile1G2
0.54user 3.55system 1:06.09elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k
2100168inputs+2097160outputs (32773major+491654minor)pagefaults 0swaps
+./test.sh:18> time ./mm_sync_madv_cp testfile1G testfile1G2
0.78user 2.91system 1:17.44elapsed 4%CPU (0avgtext+0avgdata 0maxresident)k
2100136inputs+2097160outputs (8major+524420minor)pagefaults 0swaps
+./test.sh:20> time ./mm_mun_madv_cp testfile1G testfile1G2
0.76user 3.22system 1:09.66elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
2100224inputs+2097168outputs (8major+524422minor)pagefaults 0swaps
+./test.sh:22> time ./mw_cp testfile1G testfile1G2
0.00user 4.94system 0:59.05elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
2100288inputs+2097408outputs (16391major+245892minor)pagefaults 0swaps
+./test.sh:24> time ./mw_madv_cp testfile1G testfile1G2
0.00user 5.06system 0:58.17elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
2100352inputs+2097152outputs (8major+262276minor)pagefaults 0swaps
相変わらず最速値はふつうのread-writeでのコピーですが、このぐらいだとほかの方法でもぜんぜん許せる気がします
mmap-mmapコピーの高速化（約２倍）もすごいし、madviseかけたときのページフォルトの数が約１／１０００になっています。
高負荷時に効きそうですね。
・・・
・・・・・・
・・・・・・・・・・・・
さて、次のネタをさがすか
憂鬱！ ランキング！
kzk benchの追試
http://d.hatena.ne.jp/kzk/20060513
むかーし、極一部で話題になっていたkzk bench（CP速度対決ベンチ）について、時間の余裕ができたので追試した
なお、キャッシュを追い出さないと２番手以降が最初からキャッシュに乗っていて有利すぎるので、テスト用のシェルスクリプトはちょっと変えた（以下参照）
んで、結果は以下
以下、ここから分かる考察
・syncするとまじ遅い。（が、それはあたりまえなので気にしない）
・rw_cpはぜんぜんページフォルトしてない。これが速度の秘密っぽい
・mmap-mmapコピーはまじで性能悪い。びっくり
・madviceするとページフォルト減る。これが速度向上の理由っぽげ
と、いうわけで、最速のrw_cpと最遅のmm_mun_cp（あ、syncいれてるのは遅くてあたりまえだから除いた）で動作中のiostatとvmstatをじーーーと見てみる。
まず、rw_cp
次はmm_mun_cp
一見して分かるのはiostatのIO転送速度がバッチリ違うところであるが、これは結果であって原因ではない。
なので、vmstatのほうをじーーーーとみる。
すると面白いことが分かった。rw_cpのほうはキャッシュがほぼすべてinactiveリストに載っているが、mm_mun_cpのほうは１／３ぐらいがactiveリストに残っているのだ。
すると仮説としては、
・Linuxのくそ重いページ回収まわりが遅いのが原因である
・が、rw_cpは幸運なことに、read aheadによってキャッシュに乗ったことが原因で最初から
inactive listにのった。
よって、たまたま、遅いルートに乗らなかった。
という仮説がうかぶ。
今度、シーケンシャルアクセスはactive listにのせないパッチを書いて試してみよう
むかーし、極一部で話題になっていたkzk bench（CP速度対決ベンチ）について、時間の余裕ができたので追試した
なお、キャッシュを追い出さないと２番手以降が最初からキャッシュに乗っていて有利すぎるので、テスト用のシェルスクリプトはちょっと変えた（以下参照）
#!/bin/zsh -x
SRC=testfile1G
DST=testfile1G2
TIMEX=time
PREPARE='rm $DST;sync;sync;sync;sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"'
REPEAT=1
eval $PREPARE
(repeat $REPEAT $TIMEX ./rw_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./rw_fadv_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./mm_sync_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./mm_mun_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./mm_sync_madv_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./mm_mun_madv_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./mw_cp ${SRC} ${DST})
eval $PREPARE
(repeat $REPEAT $TIMEX ./mw_madv_cp ${SRC} ${DST})
んで、結果は以下
+./test.sh:10> time ./rw_cp testfile1G testfile1G2
0.06user 2.17system 0:58.52elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+107minor)pagefaults 0swaps
+./test.sh:12> time ./rw_fadv_cp testfile1G testfile1G2
0.06user 2.38system 0:54.98elapsed 4%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+107minor)pagefaults 0swaps
+./test.sh:14> time ./mm_sync_cp testfile1G testfile1G2
0.11user 2.48system 1:43.94elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (35151major+489276minor)pagefaults 0swaps
+./test.sh:16> time ./mm_mun_cp testfile1G testfile1G2
0.10user 2.50system 1:42.32elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (35037major+489391minor)pagefaults 0swaps
+./test.sh:18> time ./mm_sync_madv_cp testfile1G testfile1G2
0.43user 3.52system 2:03.72elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (8605major+515805minor)pagefaults 0swaps
+./test.sh:20> time ./mm_mun_madv_cp testfile1G testfile1G2
0.31user 3.36system 1:41.93elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (8542major+515869minor)pagefaults 0swaps
+./test.sh:22> time ./mw_cp testfile1G testfile1G2
0.00user 2.27system 1:25.39elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (18497major+243773minor)pagefaults 0swaps
+./test.sh:24> time ./mw_madv_cp testfile1G testfile1G2
0.00user 2.94system 1:09.59elapsed 4%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (8490major+253760minor)pagefaults 0swaps
以下、ここから分かる考察
・syncするとまじ遅い。（が、それはあたりまえなので気にしない）
・rw_cpはぜんぜんページフォルトしてない。これが速度の秘密っぽい
・mmap-mmapコピーはまじで性能悪い。びっくり
・madviceするとページフォルト減る。これが速度向上の理由っぽげ
と、いうわけで、最速のrw_cpと最遅のmm_mun_cp（あ、syncいれてるのは遅くてあたりまえだから除いた）で動作中のiostatとvmstatをじーーーと見てみる。
まず、rw_cp
[kosaki@sc420 ~]$ iostat /dev/sda 10 -m
Linux 2.6.18-53.el5xen (sc420) 2008年01月01日
avg-cpu: %user %nice %system %iowait %steal %idle
1.55 0.00 2.15 67.48 0.00 28.82
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 356.94 13.01 23.08 130 231
avg-cpu: %user %nice %system %iowait %steal %idle
1.75 0.00 3.20 68.87 0.05 26.13
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 360.50 18.93 19.40 189 194
avg-cpu: %user %nice %system %iowait %steal %idle
1.45 0.00 3.50 60.83 0.00 34.22
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 339.90 19.38 15.58 193 155
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 5 266 3 0 377 0 0 6262 6791 533 563 1 2 10 88 0
0 2 266 4 0 374 0 0 11797 14728 650 863 1 7 35 58 0
0 2 266 4 0 383 0 0 9810 8648 598 732 2 4 34 61 0
0 2 266 4 0 383 0 0 11689 12560 595 795 1 6 41 52 0
0 3 266 3 0 382 0 0 10872 10546 597 779 1 5 40 54 0
1 2 266 2 0 383 0 0 10807 9652 583 779 1 4 36 58 0
1 3 266 3 0 381 0 0 10392 10254 590 786 2 5 39 55 0
0 0 266 4 0 381 0 0 5988 5431 407 559 1 3 61 35 0
0
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free inact active si so bi bo in cs us sy id wa st
0 2 266 3 368 30 0 0 15119 11773 591 658 1 2 48 49 0
0 7 266 3 373 25 0 0 14971 21259 615 711 1 2 10 86 0
0 4 266 3 372 26 0 0 18725 19391 672 761 2 3 19 77 0
1 5 266 3 371 26 0 0 18352 19450 628 742 2 3 25 71 0
0 5 266 3 371 26 0 0 19425 18876 603 748 2 3 14 81 0
0 0 266 9 369 26 0 0 7363 13603 406 540 1 2 62 34 0
0
次はmm_mun_cp
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 378.59 11.45 12.67 114 127
avg-cpu: %user %nice %system %iowait %steal %idle
0.95 0.00 4.55 60.33 0.00 34.17
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 329.40 10.03 10.49 100 104
avg-cpu: %user %nice %system %iowait %steal %idle
1.75 0.00 4.36 54.78 0.00 39.11
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 319.60 10.41 9.51 104 95
avg-cpu: %user %nice %system %iowait %steal %idle
1.05 0.00 4.79 55.31 0.05 38.80
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 323.52 10.06 10.27 100 102
[kosaki@sc420 ~]$ vmstat 10 -S M
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 3 266 237 0 127 0 0 792 757 125 258 2 1 89 8 0
0 9 266 66 0 302 0 0 12087 15989 841 854 1 7 26 66 0
2 3 266 16 0 362 0 0 7506 6304 608 617 1 2 46 51 0
9 6 267 3 0 378 0 0 11665 12942 669 829 1 5 29 65 0
0 5 267 3 0 381 0 0 10360 9941 595 794 1 5 38 55 0
0
[kosaki@sc420 ~]$ vmstat 10 -S M -a
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free inact active si so bi bo in cs us sy id wa st
0 4 266 166 189 52 0 0 793 757 125 258 2 1 89 8 0
0 11 266 65 202 138 0 0 8628 15499 708 668 1 7 22 69 0
0 4 266 13 335 56 0 0 7524 6934 609 618 1 2 45 52 0
2 4 267 9 229 165 0 0 11502 12703 661 821 1 6 30 63 0
0 3 267 3 258 142 0 0 10362 9550 593 794 1 4 39 56 0
0
一見して分かるのはiostatのIO転送速度がバッチリ違うところであるが、これは結果であって原因ではない。
なので、vmstatのほうをじーーーーとみる。
すると面白いことが分かった。rw_cpのほうはキャッシュがほぼすべてinactiveリストに載っているが、mm_mun_cpのほうは１／３ぐらいがactiveリストに残っているのだ。
すると仮説としては、
・Linuxのくそ重いページ回収まわりが遅いのが原因である
・が、rw_cpは幸運なことに、read aheadによってキャッシュに乗ったことが原因で最初から
inactive listにのった。
よって、たまたま、遅いルートに乗らなかった。
という仮説がうかぶ。
今度、シーケンシャルアクセスはactive listにのせないパッチを書いて試してみよう
