From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kosaki.motohiro@jp.fujitsu.com" <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [RFC][PATCH 0/9] memcg soft limit v2 (new design)
Date: Mon, 6 Apr 2009 14:38:00 +0530 [thread overview]
Message-ID: <20090406090800.GH7082@balbir.in.ibm.com> (raw)
In-Reply-To: <20090403170835.a2d6cbc3.kamezawa.hiroyu@jp.fujitsu.com>
* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-04-03 17:08:35]:
> Hi,
>
> Memory cgroup's soft limit feature is a feature to tell global LRU
> "please reclaim from this memcg at memory shortage".
>
> This is v2. Fixed some troubles under hierarchy. and increase soft limit
> update hooks to proper places.
>
> This patch is on to
> mmotom-Mar23 + memcg-cleanup-cache_charge.patch
> + vmscan-fix-it-to-take-care-of-nodemask.patch
>
> So, not for wide use ;)
>
> This patch tries to avoid to use existing memcg's reclaim routine and
> just tell "Hints" to global LRU. This patch is briefly tested and shows
> good result to me. (But may not to you. plz brame me.)
>
> Major characteristic is.
> - memcg will be inserted to softlimit-queue at charge() if usage excess
> soft limit.
> - softlimit-queue is a queue with priority. priority is detemined by size
> of excessing usage.
This is critical and good that you have this now. In my patchset, it
helps me achieve a lot of the expected functionality.
> - memcg's soft limit hooks is called by shrink_xxx_list() to show hints.
I am not too happy with moving pages in global LRU based on soft
limits based on my comments earlier. My objection is not too strong,
since reclaiming from the memcg also exhibits functionally similar
behaviour.
> - Behavior is affected by vm.swappiness and LRU scan rate is determined by
> global LRU's status.
>
I also have concerns about not sorting the list of memcg's. I need to
write some scalabilityt tests and check.
> In this v2.
> - problems under use_hierarchy=1 case are fixed.
> - more hooks are added.
> - codes are cleaned up.
>
> Shows good results on my private box test under several work loads.
>
> But in special artificial case, when victim memcg's Active/Inactive ratio of
> ANON is very different from global LRU, the result seems not very good.
> i.e.
> under vicitm memcg, ACTIVE_ANON=100%, INACTIVE=0% (access memory in busy loop)
> under global, ACTIVE_ANON=10%, INACTIVE=90% (almost all processes are sleeping.)
> memory can be swapped out from global LRU, not from vicitm.
> (If there are file cache in victims, file cacahes will be out.)
>
> But, in this case, even if we successfully swap out anon pages under victime memcg,
> they will come back to memory soon and can show heavy slashing.
heavy slashing? Not sure I understand what you mean.
>
> While using soft limit, I felt this is useful feature :)
> But keep this RFC for a while. I'll prepare Documentation until the next post.
>
--
Balbir
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-04-06 9:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-03 8:08 KAMEZAWA Hiroyuki
2009-04-03 8:09 ` [RFC][PATCH 1/9] " KAMEZAWA Hiroyuki
2009-04-03 8:10 ` [RFC][PATCH 2/9] soft limit framework for memcg KAMEZAWA Hiroyuki
2009-04-03 8:12 ` [RFC][PATCH 3/9] soft limit update filter KAMEZAWA Hiroyuki
2009-04-06 9:43 ` Balbir Singh
2009-04-07 0:04 ` KAMEZAWA Hiroyuki
2009-04-07 2:26 ` Balbir Singh
2009-04-03 8:12 ` [RFC][PATCH 4/9] soft limit queue and priority KAMEZAWA Hiroyuki
2009-04-06 11:05 ` Balbir Singh
2009-04-06 23:55 ` KAMEZAWA Hiroyuki
2009-04-06 18:42 ` Balbir Singh
2009-04-06 23:54 ` KAMEZAWA Hiroyuki
2009-04-03 8:13 ` [RFC][PATCH 5/9] add more hooks and check in lazy manner KAMEZAWA Hiroyuki
2009-04-03 8:14 ` [RFC][PATCH 6/9] active inactive ratio for private KAMEZAWA Hiroyuki
2009-04-03 8:15 ` [RFC][PATCH 7/9] vicitim selection logic KAMEZAWA Hiroyuki
2009-04-03 8:17 ` [RFC][PATCH 8/9] lru reordering KAMEZAWA Hiroyuki
2009-04-03 8:18 ` [RFC][PATCH 9/9] more event filter depend on priority KAMEZAWA Hiroyuki
2009-04-03 8:24 ` [RFC][PATCH ex/9] for debug KAMEZAWA Hiroyuki
2009-04-06 9:08 ` Balbir Singh [this message]
2009-04-07 0:16 ` [RFC][PATCH 0/9] memcg soft limit v2 (new design) KAMEZAWA Hiroyuki
2009-04-24 12:24 ` Balbir Singh
2009-04-24 15:19 ` KAMEZAWA Hiroyuki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090406090800.GH7082@balbir.in.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox