Re: vmscan-give-referenced-active-and-unmapped-pages-a-second-trip-around-the-lru.patch

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

Hi

Nick, Andrew, very thanks for good advice.
your helpful increase my investigate speed.


> This patch, like I said when it was first merged, has the problem that
> it can cause large stalls when reclaiming pages.
> 
> I actually myself tried a similar thing a long time ago. The problem is
> that after a long period of no reclaiming, your file pages can all end
> up being active and referenced. When the first guy wants to reclaim a
> page, it might have to scan through gigabytes of file pages before being
> able to reclaim a single one.

I perfectly agree this opinion.
all pages stay on active list is awful.

In addition, my mesurement tell me this patch cause latency degression on really heavy io workload.

2.6.27-rc8: Throughput 13.4231 MB/sec  4000 clients  4000 procs  max_latency=1421988.159 ms
 + patch  : Throughput 12.0953 MB/sec  4000 clients  4000 procs  max_latency=1731244.847 ms


> While it would be really nice to be able to just lazily set PageReferenced
> and nothing else in mark_page_accessed, and then do file page aging based
> on the referenced bit, the fact is that we virtually have O(1) reclaim
> for file pages now, and this can make it much more like O(n) (in worst case,
> especially).
> 
> I don't think it is right to say "we broke aging and this patch fixes it".
> It's all a big crazy heuristic. Who's to say that the previous behaviour
> wasn't better and this patch breaks it? :)
> 
> Anyway, I don't think it is exactly productive to keep patches like this in
> the tree (that doesn't seem ever intended to be merged) while there are
> other big changes to reclaim there.
> 
> Same for vm-dont-run-touch_buffer-during-buffercache-lookups.patch

I mesured it too,

2.6.27-rc8: Throughput 13.4231 MB/sec  4000 clients  4000 procs  max_latency=1421988.159 ms
 + patch  : Throughput 11.8494 MB/sec  4000 clients  4000 procs  max_latency=3463217.227 ms

dbench latency increased about x2.5

So, the patch desctiption already descibe this risk. 
metadata dropping can decrease performance largely.
that just appeared, imho.


I'll investigate more tommorow.
Thanks!



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>