正月から何をやっているのか自分でも分かりませんが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並。
約５％の性能向上やね。

+(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しているときはシーケンシャルアクセスとみなすようにする

の２段階で作業を進めればいいと思われる。
てか、本当になにをやっているんだか



なにをやってるの？　ランキング！

関連記事

• 最新Linuxでmm_mun_cpが実行できん (2008/01/03)
• 続々kzk benchが斬る (2008/01/03)
• kzk benchつづき (2008/01/02)

kzk benchの高速化についてまったくやる気がおきなくて、今日はだらだらすごしてしまった。 んで、最近佐藤優の一連の著作を読みまくったので...
【2008-01-03 Thu 20:11:27】 | 革命の日々！