On Thu, May 12, 2011 at 8:03 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
On Thu, 12 May 2011 17:17:25 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> On Thu, 12 May 2011 13:22:37 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> I'll check what codes in vmscan.c or /mm affects memcg and post aAfter some tests, I doubt that 'automatic' one is unnecessary until
> required fix in step by step. I think I found some..
>
memcg's dirty_ratio is supported. And as Andrew pointed out,
total cpu consumption is unchanged and I don't have workloads which
shows me meaningful speed up.
The total cpu consumption is one way to measure the background reclaim, another thing I would like to measure is a histogram of page fault latency
for a heavy page allocation application. I would expect with background reclaim, we will get less variation on the page fault latency than w/o it.
Sorry i haven't got chance to run some tests to back it up. I will try to get some data.
But I guess...with dirty_ratio, amount of dirty pages in memcg is
limited and background reclaim can work enough without noise of
write_page() while applications are throttled by dirty_ratio.
Definitely. I have run into the issue while debugging the soft_limit reclaim. The background reclaim became very inefficient if we have dirty pages greater than the soft_limit. Talking w/ Greg about it regarding his per-memcg dirty page limit effort, we should consider setting the dirty ratio which not allowing the dirty pages greater the reclaim watermarks (here is the soft_limit).
--Ying
Hmm, I'll study for a while but it seems better to start active soft limit,
(or some threshold users can set) first.
Anyway, this work makes me to see vmscan.c carefully and I think I can
post some patches for fix, tunes.
Thanks,
-Kame