From: Michal Hocko <mhocko@suse.cz>
To: linux-mm@kvack.org
Cc: cgroups@vger.kernel.org, Tejun Heo <tj@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Balbir Singh <bsingharora@gmail.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Hugh Dickins <hughd@google.com>, Ying Han <yinghan@google.com>,
Glauber Costa <glommer@parallels.com>,
Michel Lespinasse <walken@google.com>,
Greg Thelen <gthelen@google.com>
Subject: [RFC v2 0/4] soft limit rework
Date: Tue, 23 Apr 2013 11:33:55 +0200 [thread overview]
Message-ID: <1366709639-10240-1-git-send-email-mhocko@suse.cz> (raw)
In-Reply-To: <20130422183020.GF12543@htj.dyndns.org>
This is the second version of the patchset. There were some minor
cleanups since the last version and I have moved "memcg: Ignore soft
limit until it is explicitly specified" to the end of the series as it
seems to be more controversial than I thought.
The basic idea is quite simple. Pull soft reclaim into shrink_zone in
the first step and get rid of the previous soft reclaim infrastructure.
shrink_zone is done in two passes now. First it tries to do the soft
limit reclaim and it falls back to reclaim-all-mode if no group is over
the limit or no pages have been scanned. The second pass happens at the
same priority so the only time we waste is the memcg tree walk which
shouldn't be a big deal [1]. There is certainly room for improvements in
that direction. But let's keep it simple for now.
As a bonus we will get rid of a _lot_ of code by this and soft reclaim
will not stand out like before. The clean up is in a separate patch because
I felt it would be easier to review that way.
The second step is soft limit reclaim integration into targeted
reclaim. It should be rather straight forward. Soft limit has been used
only for the global reclaim so far but it makes for any kind of pressure
coming from up-the-hierarchy, including targeted reclaim.
The last step is somehow more controversial as the discussions show. I
am redefining meaning of the default soft limit value. I've not chosen
0 as we discussed previously because I want to preserve hierarchical
property of the soft limit (if a parent up the hierarchy is over its
limit then children are over as well - same as with the hard limit) so
I have kept the default untouched - unlimited - but I have slightly
changed the meaning of this value. I interpret it as "user doesn't
care about soft limit". More precisely the value is ignored unless it
has been specified by admin/user so such groups are eligible for soft
reclaim even though they do not reach the limit. Such groups do not
force their children to be reclaimed so we can look at them as neutral
for the soft reclaim.
I will attach my testing results later on.
Shortlog says:
Michal Hocko (4):
memcg: integrate soft reclaim tighter with zone shrinking code
memcg: Get rid of soft-limit tree infrastructure
vmscan, memcg: Do softlimit reclaim also for targeted reclaim
memcg: Ignore soft limit until it is explicitly specified
And the diffstat:
include/linux/memcontrol.h | 12 +-
mm/memcontrol.c | 438 +++++---------------------------------------
mm/vmscan.c | 62 ++++---
3 files changed, 88 insertions(+), 424 deletions(-)
which sounds optimistic, doesn't it?
---
[1] I have tested this by creating a hierarchy 10 levels deep with
2 groups at each level - all of them below their soft limit and a
single group eligible for the reclaim running dd reading a lot of page
cache. The system time was withing stdev comparing to the previous
implementation
--
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:[~2013-04-23 9:34 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-20 0:26 memcg: softlimit on internal nodes Tejun Heo
2013-04-20 0:42 ` Tejun Heo
2013-04-20 3:35 ` Greg Thelen
2013-04-21 1:53 ` Tejun Heo
2013-04-20 3:16 ` Michal Hocko
2013-04-21 2:23 ` Tejun Heo
2013-04-21 8:55 ` Michel Lespinasse
2013-04-22 4:24 ` Tejun Heo
2013-04-22 7:14 ` Michel Lespinasse
2013-04-22 14:48 ` Tejun Heo
2013-04-22 15:37 ` Michal Hocko
2013-04-22 15:46 ` Tejun Heo
2013-04-22 15:54 ` Michal Hocko
2013-04-22 16:01 ` Tejun Heo
2013-04-23 9:58 ` Michel Lespinasse
2013-04-23 10:17 ` Glauber Costa
2013-04-23 11:40 ` Michal Hocko
2013-04-23 11:54 ` Glauber Costa
2013-04-23 12:51 ` Michel Lespinasse
2013-04-23 13:06 ` Michal Hocko
2013-04-23 13:13 ` Glauber Costa
2013-04-23 13:28 ` Michal Hocko
2013-04-23 11:32 ` Michal Hocko
2013-04-23 12:45 ` Michel Lespinasse
2013-04-23 12:59 ` Michal Hocko
2013-04-23 12:51 ` Michal Hocko
2013-04-21 12:46 ` Michal Hocko
2013-04-22 4:39 ` Tejun Heo
2013-04-22 15:19 ` Michal Hocko
2013-04-22 15:57 ` Tejun Heo
2013-04-22 15:57 ` Tejun Heo
2013-04-22 16:20 ` Michal Hocko
2013-04-22 18:30 ` Tejun Heo
2013-04-23 9:29 ` Michal Hocko
2013-04-23 17:09 ` Tejun Heo
2013-04-26 11:51 ` Michal Hocko
2013-04-26 18:37 ` Tejun Heo
2013-04-29 15:27 ` Michal Hocko
2013-04-23 9:33 ` Michal Hocko [this message]
2013-04-23 9:33 ` [RFC v2 1/4] memcg: integrate soft reclaim tighter with zone shrinking code Michal Hocko
2013-04-23 9:33 ` [RFC v2 2/4] memcg: Get rid of soft-limit tree infrastructure Michal Hocko
2013-04-23 9:33 ` [RFC v2 3/4] vmscan, memcg: Do softlimit reclaim also for targeted reclaim Michal Hocko
2013-04-23 9:33 ` [RFC v2 4/4] memcg: Ignore soft limit until it is explicitly specified Michal Hocko
2013-04-24 21:45 ` memcg: softlimit on internal nodes Johannes Weiner
2013-04-25 0:33 ` Tejun Heo
2013-04-29 18:39 ` Johannes Weiner
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=1366709639-10240-1-git-send-email-mhocko@suse.cz \
--to=mhocko@suse.cz \
--cc=bsingharora@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=glommer@parallels.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=tj@kernel.org \
--cc=walken@google.com \
--cc=yinghan@google.com \
/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;
as well as URLs for NNTP newsgroup(s).