Re: [rfc patch 0/6] mm: memcg naturalization

[Ying Han <yinghan@google.com>]

[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]

On Fri, May 13, 2011 at 12:20 AM, Johannes Weiner <hannes@cmpxchg.org>wrote:

> On Thu, May 12, 2011 at 11:53:37AM -0700, Ying Han wrote:
> > On Thu, May 12, 2011 at 7:53 AM, Johannes Weiner <hannes@cmpxchg.org>
> wrote:
> >
> > > Hi!
> > >
> > > Here is a patch series that is a result of the memcg discussions on
> > > LSF (memcg-aware global reclaim, global lru removal, struct
> > > page_cgroup reduction, soft limit implementation) and the recent
> > > feature discussions on linux-mm.
> > >
> > > The long-term idea is to have memcgs no longer bolted to the side of
> > > the mm code, but integrate it as much as possible such that there is a
> > > native understanding of containers, and that the traditional !memcg
> > > setup is just a singular group.  This series is an approach in that
> > > direction.
>

This sounds like a good long term plan. Now I would wonder should we take it
step by step by doing:

1. improving the existing soft_limit reclaim from RB-tree based to link-list
based, also in a round_robin fashion.
We can keep the existing APIs but only changing the underlying
implementation of  mem_cgroup_soft_limit_reclaim()

2. remove the global lru list after the first one being proved to be
efficient.

3. then have better integration of memcg reclaim to the mm code.

--Ying


> > >
> > > It is a rather early snapshot, WIP, barely tested etc., but I wanted
> > > to get your opinions before further pursuing it.  It is also part of
> > > my counter-argument to the proposals of adding memcg-reclaim-related
> > > user interfaces at this point in time, so I wanted to push this out
> > > the door before things are merged into .40.
> > >
> >
> > The memcg-reclaim-related user interface I assume was the watermark
> > configurable tunable we were talking about in the per-memcg
> > background reclaim patch. I think we got some agreement to remove
> > the watermark tunable at the first step. But the newly added
> > memory.soft_limit_async_reclaim as you proposed seems to be a usable
> > interface.
>
> Actually, I meant the soft limit reclaim statistics.  There is a
> comment about that in the 6/6 changelog.
>

Ok get it now. I will move the discussion to that thread.

[-- Attachment #2: Type: text/html, Size: 3052 bytes --]