わりと小さくて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);
パッチぐらいいくらでも見せますがな
コメント
コメント一覧 (5)
oprofileのデータとか採取していただけるとうれしいっす。
データがあるとどうだということではないのですが、どこが速くなったのかなんてことがミクロに分かってうれしいっす。
# opcontrol --reset
# opcontrol --start
# ベンチマークの実行
# opcontrol --stop
# opreport -l
I/O関係はCPUは寝まくっているのでOprofileではなんも出ません。
ソース見て、「きっとココ！」って直感できるかどうかが勝負です。
IO帯域を十分食い切るようにストレージやらなんやらを調整しないといかんっすよ。
寝まくっているのをtimeではかって何％向上したとかなんとかというのには説得力ないと思うっすよ。
搭載メモリ量を超えるコピーをしておいて寝ないなんてRAID組んだって無理ですよ。
今回のベンチマークは実アプリ動作を意識したベンチじゃなくて、搭載メモリ量を超える大きさのファイルのコピーをするというマイクロベンチマークなので寝るのは正しい。
そもそもメモリ量を超える大きさのファイルをコピーするなっていうなら、
今回のベンチマークを全否定してるっすよ。
搭載メモリ、CPU、ストレージの諸元。あとvmstatのデータとかどーなっているっすか。
搭載メモリを越えるファイルをコピーする場合でもRAID0で十分バンド幅をとれればCPUぶん回せるんじゃないっすか。