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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Apr 20, 2011 at 9:00 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
On Thu, 21 Apr 2011 04:51:07 +0200
Johannes Weiner <hannes@xxxxxxxxxxx> 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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]