プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

kzk benchその後 このエントリーをはてなブックマークに追加

わりと小さくて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が100以下が高速化である。
勝手な理屈だが10%程度以上の高速化を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 | 【2008-01-13(Sun) 23:24:47】 | Trackback:(0) | Comments:(5)
コメント
せんせー、質問です。

oprofileのデータとか採取していただけるとうれしいっす。
データがあるとどうだということではないのですが、どこが速くなったのかなんてことがミクロに分かってうれしいっす。

# opcontrol --reset
# opcontrol --start
# ベンチマークの実行
# opcontrol --stop
# opreport -l
2008-01-15 火 03:54:14 | URL | hyoshiok #OLXj00Ls [ 編集]

むりむり。
I/O関係はCPUは寝まくっているのでOprofileではなんも出ません。
ソース見て、「きっとココ!」って直感できるかどうかが勝負です。
2008-01-15 火 08:21:33 | URL | kosaki #- [ 編集]
IOで寝まくっているとしたら、それはベンチマーク環境がおかしい。
IO帯域を十分食い切るようにストレージやらなんやらを調整しないといかんっすよ。

寝まくっているのをtimeではかって何%向上したとかなんとかというのには説得力ないと思うっすよ。
2008-01-16 水 03:45:57 | URL | hyoshiok #OLXj00Ls [ 編集]

んなバカな。
搭載メモリ量を超えるコピーをしておいて寝ないなんてRAID組んだって無理ですよ。

今回のベンチマークは実アプリ動作を意識したベンチじゃなくて、搭載メモリ量を超える大きさのファイルのコピーをするというマイクロベンチマークなので寝るのは正しい。

そもそもメモリ量を超える大きさのファイルをコピーするなっていうなら、
今回のベンチマークを全否定してるっすよ。
2008-01-16 水 06:49:31 | URL | kosaki #- [ 編集]

脊髄反射してしまったことに若干の反省を感じつつ、今回のベンチマークの環境がどうなっているか教えて下さい。

搭載メモリ、CPU、ストレージの諸元。あとvmstatのデータとかどーなっているっすか。

搭載メモリを越えるファイルをコピーする場合でもRAID0で十分バンド幅をとれればCPUぶん回せるんじゃないっすか。
2008-01-16 水 19:03:03 | URL | hyoshiok #OLXj00Ls [ 編集]
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。