On Wed, Apr 20, 2011 at 9:00 PM, KAMEZAWA Hiroyuki <
kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Thu, 21 Apr 2011 04:51:07 +0200
> Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> > > If the cgroup is configured to use per cgroup background reclaim, a
> kswapd
> > > thread is created which only scans the per-memcg LRU list.
> >
> > We already have direct reclaim, direct reclaim on behalf of a memcg,
> > and global kswapd-reclaim.  Please don't add yet another reclaim path
> > that does its own thing and interacts unpredictably with the rest of
> > them.
> >
> > As discussed on LSF, we want to get rid of the global LRU.  So the
> > goal is to have each reclaim entry end up at the same core part of
> > reclaim that round-robin scans a subset of zones from a subset of
> > memory control groups.
> >
>
> It's not related to this set. And I think even if we remove global LRU,
> global-kswapd and memcg-kswapd need to do independent work.
>
> global-kswapd : works for zone/node balancing and making free pages,
>                and compaction. select a memcg vicitm and ask it
>                to reduce memory with regard to gfp_mask. Starts its work
>                when zone/node is unbalanced.
>
> memcg-kswapd  : works for reducing usage of memory, no interests on
>                zone/nodes. Starts when high/low watermaks hits.
>
> We can share 'recalim_memcg_this_zone()' code finally, but it can be
> changed when we remove global LRU.
>
>
> > > Two watermarks ("high_wmark", "low_wmark") are added to trigger the
> > > background reclaim and stop it. The watermarks are calculated based
> > > on the cgroup's limit_in_bytes.
> >
> > Which brings me to the next issue: making the watermarks configurable.
> >
> > You argued that having them adjustable from userspace is required for
> > overcommitting the hardlimits and per-memcg kswapd reclaim not kicking
> > in in case of global memory pressure.  But that is only a problem
> > because global kswapd reclaim is (apart from soft limit reclaim)
> > unaware of memory control groups.
> >
> > I think the much better solution is to make global kswapd memcg aware
> > (with the above mentioned round-robin reclaim scheduler), compared to
> > adding new (and final!) kernel ABI to avoid an internal shortcoming.
> >
>
> I don't think its a good idea to kick kswapd even when free memory is
> enough.
>
> If memcg-kswapd implemted, I'd like to add auto-cgroup for memcg-kswapd and
> limit its cpu usage because it works even when memory is not in-short.
>

How are we gonna isolate the memcg-kswapd cpu usage under the workqueue
model?

--Ying

>
>
> Thanks,
> -Kame
>
>
>