On Thu, May 12, 2011 at 8:03 PM, KAMEZAWA Hiroyuki <
kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Thu, 12 May 2011 17:17:25 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> > On Thu, 12 May 2011 13:22:37 +0900
> > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > I'll check what codes in vmscan.c or /mm affects memcg and post a
> > required fix in step by step. I think I found some..
> >
>
> After some tests, I doubt that 'automatic' one is unnecessary until
> 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
>
>