On Wed, Apr 20, 2011 at 9:00 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
On Thu, 21 Apr 2011 04:51:07 +0200
> > If the cgroup is configured to use per cgroup background reclaim, a kswapdIt's not related to this set. And I think even if we remove global LRU,
> > 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.
>
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.
I don't think its a good idea to kick kswapd even when free memory is enough.
> > 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.
>
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