Re: [PATCH V6 00/10] memcg: per cgroup background reclaim

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

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.


Thanks,
-Kame


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>