On Fri, Apr 22, 2011 at 6:35 PM, Johannes Weiner <hannes@cmpxchg.org> wrote:

> On Wed, Apr 20, 2011 at 10:28:17PM -0700, Ying Han wrote:
> > On Wed, Apr 20, 2011 at 10:08 PM, Johannes Weiner <hannes@cmpxchg.org
> >wrote:
> > > On Thu, Apr 21, 2011 at 01:00:16PM +0900, KAMEZAWA Hiroyuki wrote:
> > > > I don't think its a good idea to kick kswapd even when free memory is
> > > enough.
> > >
> > > This depends on what kswapd is supposed to be doing.  I don't say we
> > > should reclaim from all memcgs (i.e. globally) just because one memcg
> > > hits its watermark, of course.
> > >
> > > But the argument was that we need the watermarks configurable to force
> > > per-memcg reclaim even when the hard limits are overcommitted, because
> > > global reclaim does not do a fair job to balance memcgs.
> >
> > There seems to be some confusion here. The watermark we defined is
> > per-memcg, and that is calculated
> > based on the hard_limit. We need the per-memcg wmark the same reason of
> > per-zone wmart which triggers
> > the background reclaim before direct reclaim.
>
> Of course, I am not arguing against the watermarks.  I am just
> (violently) against making them configurable from userspace.
>
> > There is a patch in my patchset which adds the tunable for both
> > high/low_mark, which gives more flexibility to admin to config the host.
> In
> > over-commit environment, we might never hit the wmark if all the wmarks
> are
> > set internally.
>
> And my point is that this should not be a problem at all!  If the
> watermarks are not physically reachable, there is no reason to reclaim
> on behalf of them.
>
> In such an environment, global memory pressure arises before the
> memcgs get close to their hard limit, and global memory pressure
> reduction should do the right thing and equally push back all memcgs.
>
> Flexibility in itself is not an argument.  On the contrary.  We commit
> ourselves to that ABI and have to maintain this flexibility forever.
> Instead, please find a convincing argument for the flexibility itself,
> other than the need to workaround the current global kswapd reclaim.
>
> Ok, I tend to agree with you now that the over-commit example i gave early
is a weak argument. We don't need to provide the ability to reclaim from a
memcg before it is reaching its wmarks in over-commit environment.

However, i still think there is a need from the admin to have some controls
of which memcg to do background reclaim proactively (before global memory
pressure) and that was the initial logic behind the API.

I used to have per-memcg wmark_ratio api which controls both high/low_wmark
based on hard_limit, but the two APIs seems give finer granularity.

--Ying


> (I fixed up the following quotation, please be more careful when
> replying, this makes it so hard to follow your emails.  thanks!)
>
> > > My counter proposal is to fix global reclaim instead and apply equal
> > > pressure on memcgs, such that we never have to tweak per-memcg
> watermarks
> > > to achieve the same thing.
> >
> > We still need this and that is the soft_limit reclaim under global
> > background reclaim.
>
> I don't understand what you mean by that.  Could you elaborate?
>

Sorry I think I misunderstood your early comment. What I pointed out here
was that we need both per-memcg
background reclaim and global soft_limit reclaim. I don't think we have
disagreement on that at this point.

>
> Thanks,
>
>        Hannes
>