あやしげなメッセージとともにダンマリしてしまう。
ショボーン(´･ω･｀)
ブートパラメタに書いたcrashkernel=128M@16M オプションが正しく認識されていることは
/proc/iomemにて確認済みだし。
おなじく、/proc/iomemにてe0000000 がreservedであることは確認できてるんだけど・・・
むむむ・・・
ショボーン(´･ω･｀)
sc420 login: SysRq : Trigger a crashdump
Memory for crash kernel (0x0 to 0x0) notwithin permissible range
PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved
PCI: Not using MMCONFIG.
ACPI: Getting cpuindex for acpiid 0x2
Mounting proc filesystem
Mounting sysfs filesys
ブートパラメタに書いたcrashkernel=128M@16M オプションが正しく認識されていることは
/proc/iomemにて確認済みだし。
おなじく、/proc/iomemにてe0000000 がreservedであることは確認できてるんだけど・・・
むむむ・・・
LKMLの [RFC] Parallelize IO for e2fsck なるスレッドでmem_notify に言及されてたらしいんだけど、ｃｃされてなかったので、まったく気づかなかったよ。
mel にたのまれたtestをするために、近くのパソコンショップでシリアルのクロスケーブルを買ってきた。こんなん買うの１０年ぶりかもしれん。
Linuxで起動時にパニックしちゃう場合シリアルケーブルつなげておかないとデバッグがほぼ不可能なのだよ。
で、帰ってみると衝撃の事実が！！
ぼくちんのWindowsマシンにはなんとシリアルポートがなかった。イマドキのWindowsってそうなのねｗｗｗｗ
しょうがないから、取って返してUSB - シリアル変換機も買ってきた。バカス。
てゆーか、ちょっとした善意で６千円も飛んでいくのは若干納得行かないような。むむ。
で、Linux側の設定なのだが/boot/grub/grub.confの以下の箇所を変更すればOK
参考URL
JF文書 :http://www.linux.or.jp/JF/JFdocs/Remote-Serial-Console-HOWTO/index.html
ITメディア： http://www.itmedia.co.jp/help/tips/linux/l0617.html
第３のペンギン： http://blog.miraclelinux.com/thethird/2007/02/linux_fb95.html
USBをシリアルコンソールに： http://www.irori.org/doc/usb-console.html
Linuxで起動時にパニックしちゃう場合シリアルケーブルつなげておかないとデバッグがほぼ不可能なのだよ。
で、帰ってみると衝撃の事実が！！
ぼくちんのWindowsマシンにはなんとシリアルポートがなかった。イマドキのWindowsってそうなのねｗｗｗｗ
しょうがないから、取って返してUSB - シリアル変換機も買ってきた。バカス。
てゆーか、ちょっとした善意で６千円も飛んでいくのは若干納得行かないような。むむ。
で、Linux側の設定なのだが/boot/grub/grub.confの以下の箇所を変更すればOK
default=3
timeout=5
#splashimage=(hd0,0)/grub/splash.xpm.gz
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
hiddenmenu
title CentOS (2.6.18-53.1.4.el5PAE)
root (hd0,0)
kernel /vmlinuz-2.6.18-53.1.4.el5PAE ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.18-53.1.4.el5PAE.img
title kosatest
root (hd0,0)
kernel /vmlinuz-kosatest ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tty0 console=ttyS0,9600n8r
initrd /initrd-kosatest.img
参考URL
JF文書 :http://www.linux.or.jp/JF/JFdocs/Remote-Serial-Console-HOWTO/index.html
ITメディア： http://www.itmedia.co.jp/help/tips/linux/l0617.html
第３のペンギン： http://blog.miraclelinux.com/thethird/2007/02/linux_fb95.html
USBをシリアルコンソールに： http://www.irori.org/doc/usb-console.html
Alan Cox先生に要望されていたfasyncサポートが実装できたので、mem_notify v5としてポストした。
だんだん飽きてきたので、誰か目新しいコメントくれんかのぅ
だんだん飽きてきたので、誰か目新しいコメントくれんかのぅ
イマドキのイリピーさんは目から怪光線を出して、周囲をなぎ払えるらしい。
むらむらするな
むらむらするな
どうもあまり有名ではないらしいので、ここで書いてみる。
http://mkosaki.blog46.fc2.com/blog-entry-241.html
で書いた事とほぼ同じだけれど。
Linuxにおいて、CPU負荷を測定するベンチマークでは以下の環境変数を設定すると往々にして性能があがる。
% setenv MALLOC_TRIM_THRESHOLD_ -1
% setenv MALLOC_MMAP_MAX_ 0
MALLOC_TRIM_THRESHOLD_ はOSに未使用になったメモリを返却する契機をあらわしていて、−１は決して返却しない事を表す。
MALLOC_MMAP_MAX_ は最大mmap数で０は決してmmapせず、どんなに大きなメモリでもbrkを使ってメモリを取る事を意味する。
で、性能に効くのは（たいてい）MALLOC_MMAP_MAX_のほう。
glibcはアンチフラグメンテーションの観点から一定以上（たしかデフォルト１M）の大きさのmallocは内部で直接mmap呼び出しをするように変換される。
で、これがある種の状況下では、２重の意味で悪い効果をもたらす。
１．キャッシュコンフリクト
まあ、実装がへこいのですがmmap呼び出すときにキャッシュカラーリングのコードが
はいってないんです。
なので、戻り値アドレスが全部ページバウンダリにそろってしまっています。
なので複数スレッドがmalloc復帰値を同じようなアクセスパターンでアクセスしていくと
がんがんキャッシュコンフリクトします。
２．munmapネック
mmapしたやつはbrkでとったやつと違い、フリーリスト管理はせずに、アプリがfree(3)を
呼んだら、すぐさまOSにmunmapする実装になっています。
で、特に大規模SMPにおいて、munmapはmmapと違ってlazyに処理できないので、
非常にコストが高い操作である。と
大抵のアーキで全CPUに割り込みとばして空間そぎ落として返事がくるのをじっと
まっているので。
かつ、Linuxにおいてドライバが数ミリ秒ぐらい割禁とかするのはめずらしくないので、
一番遅いCPUに引っ張られてますます遅くなる。
もちろん、この環境変数を設定するとヒープフラグメンテーションが進みやすくなるので３６５日動き続ける業務アプリで設定するものは考え物であるが、ベンチマークの数字的には結構効果があるので、ベンチマーク屋さんは、オマジナイ代わりに試してみる価値はある。
おまじない代わり！ ランキング！
http://mkosaki.blog46.fc2.com/blog-entry-241.html
で書いた事とほぼ同じだけれど。
Linuxにおいて、CPU負荷を測定するベンチマークでは以下の環境変数を設定すると往々にして性能があがる。
% setenv MALLOC_TRIM_THRESHOLD_ -1
% setenv MALLOC_MMAP_MAX_ 0
MALLOC_TRIM_THRESHOLD_ はOSに未使用になったメモリを返却する契機をあらわしていて、−１は決して返却しない事を表す。
MALLOC_MMAP_MAX_ は最大mmap数で０は決してmmapせず、どんなに大きなメモリでもbrkを使ってメモリを取る事を意味する。
で、性能に効くのは（たいてい）MALLOC_MMAP_MAX_のほう。
glibcはアンチフラグメンテーションの観点から一定以上（たしかデフォルト１M）の大きさのmallocは内部で直接mmap呼び出しをするように変換される。
で、これがある種の状況下では、２重の意味で悪い効果をもたらす。
１．キャッシュコンフリクト
まあ、実装がへこいのですがmmap呼び出すときにキャッシュカラーリングのコードが
はいってないんです。
なので、戻り値アドレスが全部ページバウンダリにそろってしまっています。
なので複数スレッドがmalloc復帰値を同じようなアクセスパターンでアクセスしていくと
がんがんキャッシュコンフリクトします。
２．munmapネック
mmapしたやつはbrkでとったやつと違い、フリーリスト管理はせずに、アプリがfree(3)を
呼んだら、すぐさまOSにmunmapする実装になっています。
で、特に大規模SMPにおいて、munmapはmmapと違ってlazyに処理できないので、
非常にコストが高い操作である。と
大抵のアーキで全CPUに割り込みとばして空間そぎ落として返事がくるのをじっと
まっているので。
かつ、Linuxにおいてドライバが数ミリ秒ぐらい割禁とかするのはめずらしくないので、
一番遅いCPUに引っ張られてますます遅くなる。
もちろん、この環境変数を設定するとヒープフラグメンテーションが進みやすくなるので３６５日動き続ける業務アプリで設定するものは考え物であるが、ベンチマークの数字的には結構効果があるので、ベンチマーク屋さんは、オマジナイ代わりに試してみる価値はある。
おまじない代わり！ ランキング！
Andrew Morton先生にそんなルートは絶対に通らないと言われたので、
うるへー、いいからやってみろ
と返信してしまった。
もうちょっと言葉遣いを考えましょう。反省。
うるへー、いいからやってみろ
と返信してしまった。
もうちょっと言葉遣いを考えましょう。反省。
quiltの結果のdiffstatがおかしいと思っていたら .quiltrcがスペルミスってた。
おかげでLKMLで恥をかいたわい (馬ﾟ∀ﾟ鹿)♪
おかげでLKMLで恥をかいたわい (馬ﾟ∀ﾟ鹿)♪
kzk bench改良パッチとmem notify patch v4をLKMLに投げた。
後は野となれ山となれ(ﾟдﾟ｀)
後は野となれ山となれ(ﾟдﾟ｀)
わりと小さくてmmap copyがちゃんと高速化できるパッチができたような気がする
2.6.24-rc6 +my patch ratio
-------------------------------------------------
rw_cp 59.32 58.60 98.79%
rw_fadv_cp 57.96 57.96 100.0%
mm_sync_cp 69.97 61.68 88.15%
mm_sync_madv_cp 69.41 62.54 90.10%
mw_cp 61.69 63.11 102.30%
mw_madv_cp 61.35 61.31 99.93%
ratioが１００以下が高速化である。
勝手な理屈だが１０％程度以上の高速化をsignificantと定義している。
パッチの説明だが、メモリが不足したときのページ回収論理においてaccessed bitが立っていたページを残し、それ以外を捨てる。という論理があるのだが、そこに
・周辺のページがずっと、accessed bitが立ち続けていたらmmaped copy中とみなしてaccessed bitを無視する
という論理がいれてある。
本格的にやるにはpage->flagsにフラグビットを追加しないといけないが、Linuxにおいてそれはフレームの元なので、強引に避けてある。
来週ぐらいにlinux-mmに投げてみるべ
パッチぐらいいくらでも見せますがな
2.6.24-rc6 +my patch ratio
-------------------------------------------------
rw_cp 59.32 58.60 98.79%
rw_fadv_cp 57.96 57.96 100.0%
mm_sync_cp 69.97 61.68 88.15%
mm_sync_madv_cp 69.41 62.54 90.10%
mw_cp 61.69 63.11 102.30%
mw_madv_cp 61.35 61.31 99.93%
ratioが１００以下が高速化である。
勝手な理屈だが１０％程度以上の高速化をsignificantと定義している。
パッチの説明だが、メモリが不足したときのページ回収論理においてaccessed bitが立っていたページを残し、それ以外を捨てる。という論理があるのだが、そこに
・周辺のページがずっと、accessed bitが立ち続けていたらmmaped copy中とみなしてaccessed bitを無視する
という論理がいれてある。
本格的にやるにはpage->flagsにフラグビットを追加しないといけないが、Linuxにおいてそれはフレームの元なので、強引に避けてある。
来週ぐらいにlinux-mmに投げてみるべ
---
mm/vmscan.c | 46 +++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 43 insertions(+), 3 deletions(-)
Index: linux-2.6.24-rc6-cp3/mm/vmscan.c
===================================================================
--- linux-2.6.24-rc6-cp3.orig/mm/vmscan.c 2008-01-13 21:58:03.000000000 +0900
+++ linux-2.6.24-rc6-cp3/mm/vmscan.c 2008-01-13 22:30:27.000000000 +0900
@@ -446,13 +446,18 @@ static unsigned long shrink_page_list(st
struct pagevec freed_pvec;
int pgactivate = 0;
unsigned long nr_reclaimed = 0;
+ unsigned long nr_scanned = 0;
+ LIST_HEAD(l_mapped_pages);
+ unsigned long nr_mapped_page_activate = 0;
+ struct page *page;
+ int reference_checked = 0;
cond_resched();
pagevec_init(&freed_pvec, 1);
+retry:
while (!list_empty(page_list)) {
struct address_space *mapping;
- struct page *page;
int may_enter_fs;
int referenced;
@@ -466,6 +471,7 @@ static unsigned long shrink_page_list(st
VM_BUG_ON(PageActive(page));
+ nr_scanned++;
sc->nr_scanned++;
if (!sc->may_swap && page_mapped(page))
@@ -493,11 +499,17 @@ static unsigned long shrink_page_list(st
goto keep_locked;
}
- 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))
- goto activate_locked;
+ if (!reference_checked) {
+ 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)) {
+ nr_mapped_page_activate++;
+ unlock_page(page);
+ list_add(&page->lru, &l_mapped_pages);
+ continue;
+ }
+ }
#ifdef CONFIG_SWAP
/*
@@ -604,7 +616,31 @@ keep:
list_add(&page->lru, &ret_pages);
VM_BUG_ON(PageLRU(page));
}
+
+ if (nr_scanned == nr_mapped_page_activate) {
+ /* may be under copy by mmap.
+ ignore reference flag. */
+ reference_checked = 1;
+ list_splice(&l_mapped_pages, page_list);
+ goto retry;
+ } else {
+ /* move active list just now */
+ while (!list_empty(&l_mapped_pages)) {
+ page = lru_to_page(&l_mapped_pages);
+ list_del(&page->lru);
+ prefetchw_prev_lru_page(page, &l_mapped_pages, flags);
+
+ if (!TestSetPageLocked(page)) {
+ SetPageActive(page);
+ pgactivate++;
+ unlock_page(page);
+ }
+ list_add(&page->lru, &ret_pages);
+ }
+ }
+
list_splice(&ret_pages, page_list);
+
if (pagevec_count(&freed_pvec))
__pagevec_release_nonlru(&freed_pvec);
count_vm_events(PGACTIVATE, pgactivate);
パッチぐらいいくらでも見せますがな
とおもったら、とっくの昔にlinux-mmにパッチでてた。
しかし、i386が動かなくなるようなパッチを投げる気がしれんな。
とりあえず、mem_notify v4の作業はすべて完了。
来週頭ぐらいに一度なげるべ。
しかし、i386が動かなくなるようなパッチを投げる気がしれんな。
とりあえず、mem_notify v4の作業はすべて完了。
来週頭ぐらいに一度なげるべ。
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の内容を空気読まずにギークに転載しちゃうのがよくねーと思うだわよ。別にプレスリリースとかで語ったわけじゃないんでしょ。
違う世界の文化も受け入れてあげるべきだと思うな
とか思ったり、思わなかったり。
駄文。。。
って、もう８日やぞ！
いくら引越しして転送されてるからって遅すぎないか？！
＃１０枚ぐらいいっきに来たので、差出人のみなさんは１／１に届くようにしていたと思われる
いまから返事を書いても時期はずれだしなー。どうしようかなー
それをいいわけにして返事をさぼるかー
いくら引越しして転送されてるからって遅すぎないか？！
＃１０枚ぐらいいっきに来たので、差出人のみなさんは１／１に届くようにしていたと思われる
いまから返事を書いても時期はずれだしなー。どうしようかなー
それをいいわけにして返事をさぼるかー
最近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;';';'/:.:.:.:.:.:.:.:.:.|. ＼:::::＼::::: ヽ ::::::!′ :::| .:/
. ｌ |:.:.:.:.:.:.:∨:.:.:.:.:.:.:.:.:.:.:.! /ヽ::: `::: :::: ....::....／
・・・・だめだ
無理がありすぎる。
やる気をだすなんて無理。
だめだ、こいつ分かってねー
/::::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ﾞ､ ￣ .／ , |::!
/ ﾍ ヾ ヽ､ _,. ' / |:'
どうもメモリ管理が変わった拍子に
この定理に関して、私は真に驚くべき証明を見つけたが、この32bitアドレス空間はそれをmmapするには狭すぎる
と遺言されてしまっているらしい。南無
この定理に関して、私は真に驚くべき証明を見つけたが、この32bitアドレス空間はそれをmmapするには狭すぎる
と遺言されてしまっているらしい。南無
正月から何をやっているのか自分でも分かりませんが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しているときはシーケンシャルアクセスとみなすようにする
の２段階で作業を進めればいいと思われる。
てか、本当になにをやっているんだか
なにをやってるの？ ランキング！
欝展開というやつですね。
改造しやすいようにと、最新カーネルビルドして再テストしたらめっさ速いんでやんの。
やる気なくすわー
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かけたときのページフォルトの数が約１／１０００になっています。
高負荷時に効きそうですね。
・・・
・・・・・・
・・・・・・・・・・・・
さて、次のネタをさがすか
憂鬱！ ランキング！