From: Glauber Costa <glommer@gmail.com>
To: linux-mm@kvack.org
Cc: linux-fsdevel@vger.kernel.org, mgorman@suse.de,
david@fromorbit.com, cgroups@vger.kernel.org,
kamezawa.hiroyu@jp.fujitsu.com, mhocko@suze.cz,
hannes@cmpxchg.org, hughd@google.com, gthelen@google.com,
akpm@linux-foundation.org, Glauber Costa <glommer@openvz.org>,
Michal Hocko <mhocko@suse.cz>
Subject: [PATCH v10 13/16] memcg: allow kmem limit to be resized down
Date: Sun, 7 Jul 2013 11:56:53 -0400 [thread overview]
Message-ID: <1373212616-11713-14-git-send-email-glommer@openvz.org> (raw)
In-Reply-To: <1373212616-11713-1-git-send-email-glommer@openvz.org>
The userspace memory limit can be freely resized down. Upon attempt,
reclaim will be called to flush the pages away until we either reach the
limit we want or give up.
It wasn't possible so far with the kmem limit, since we had no way to
shrink the kmem buffers other than using the big hammer of shrink_slab,
that effectively frees data around the whole system.
The situation flips now that we have a per-memcg shrinker
infrastructure. We will proceed analogously to our user memory
counterpart and try to shrink our buffers until we either reach the
limit we want or give up.
Signed-off-by: Glauber Costa <glommer@openvz.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
mm/memcontrol.c | 43 ++++++++++++++++++++++++++++++++++++++-----
1 file changed, 38 insertions(+), 5 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index cce8a22..8623172 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5446,10 +5446,39 @@ static ssize_t mem_cgroup_read(struct cgroup *cont, struct cftype *cft,
return simple_read_from_buffer(buf, nbytes, ppos, str, len);
}
+#ifdef CONFIG_MEMCG_KMEM
+/*
+ * This is slightly different than res or memsw reclaim. We already have
+ * vmscan behind us to drive the reclaim, so we can basically keep trying until
+ * all buffers that can be flushed are flushed. We have a very clear signal
+ * about it in the form of the return value of try_to_free_mem_cgroup_kmem.
+ */
+static int mem_cgroup_resize_kmem_limit(struct mem_cgroup *memcg,
+ unsigned long long val)
+{
+ int ret = -EBUSY;
+
+ for (;;) {
+ if (signal_pending(current)) {
+ ret = -EINTR;
+ break;
+ }
+
+ ret = res_counter_set_limit(&memcg->kmem, val);
+ if (!ret)
+ break;
+
+ /* Can't free anything, pointless to continue */
+ if (!try_to_free_mem_cgroup_kmem(memcg, GFP_KERNEL))
+ break;
+ }
+
+ return ret;
+}
+
static int memcg_update_kmem_limit(struct cgroup *cont, u64 val)
{
int ret = -EINVAL;
-#ifdef CONFIG_MEMCG_KMEM
struct mem_cgroup *memcg = mem_cgroup_from_cont(cont);
/*
* For simplicity, we won't allow this to be disabled. It also can't
@@ -5484,16 +5513,15 @@ static int memcg_update_kmem_limit(struct cgroup *cont, u64 val)
* starts accounting before all call sites are patched
*/
memcg_kmem_set_active(memcg);
- } else
- ret = res_counter_set_limit(&memcg->kmem, val);
+ } else {
+ ret = mem_cgroup_resize_kmem_limit(memcg, val);
+ }
out:
mutex_unlock(&set_limit_mutex);
mutex_unlock(&memcg_create_mutex);
-#endif
return ret;
}
-#ifdef CONFIG_MEMCG_KMEM
static int memcg_propagate_kmem(struct mem_cgroup *memcg)
{
int ret = 0;
@@ -5530,6 +5558,11 @@ static int memcg_propagate_kmem(struct mem_cgroup *memcg)
out:
return ret;
}
+#else
+static int memcg_update_kmem_limit(struct cgroup *cont, u64 val)
+{
+ return -EINVAL;
+}
#endif /* CONFIG_MEMCG_KMEM */
/*
--
1.8.2.1
next prev parent reply other threads:[~2013-07-07 15:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-07 15:56 [PATCH v10 00/16] kmemcg shrinkers Glauber Costa
2013-07-07 15:56 ` [PATCH v10 01/16] memcg: make cache index determination more robust Glauber Costa
2013-07-07 15:56 ` [PATCH v10 02/16] memcg: consolidate callers of memcg_cache_id Glauber Costa
2013-07-07 15:56 ` [PATCH v10 03/16] vmscan: also shrink slab in memcg pressure Glauber Costa
2013-07-07 15:56 ` [PATCH v10 04/16] memcg: move stop and resume accounting functions Glauber Costa
2013-07-07 15:56 ` [PATCH v10 05/16] memcg,list_lru: duplicate LRUs upon kmemcg creation Glauber Costa
[not found] ` <1373212616-11713-1-git-send-email-glommer-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2013-07-07 15:56 ` [PATCH v10 06/16] lru: add an element to a memcg list Glauber Costa
2013-07-07 15:56 ` [PATCH v10 07/16] list_lru: per-memcg walks Glauber Costa
2013-07-07 15:56 ` [PATCH v10 09/16] memcg: per-memcg kmem shrinking Glauber Costa
2013-07-07 15:56 ` [PATCH v10 11/16] vmscan: take at least one pass with shrinkers Glauber Costa
2013-07-07 15:56 ` [PATCH v10 15/16] memcg: reap dead memcgs upon global memory pressure Glauber Costa
2013-07-07 15:56 ` [PATCH v10 08/16] memcg: move initialization to memcg creation Glauber Costa
2013-07-07 15:56 ` [PATCH v10 10/16] memcg: scan cache objects hierarchically Glauber Costa
2013-07-07 15:56 ` [PATCH v10 12/16] super: targeted memcg reclaim Glauber Costa
2013-07-07 15:56 ` Glauber Costa [this message]
2013-07-07 15:56 ` [PATCH v10 14/16] vmpressure: in-kernel notifications Glauber Costa
2013-07-07 15:56 ` [PATCH v10 16/16] memcg: flush memcg items upon memcg destruction Glauber Costa
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=1373212616-11713-14-git-send-email-glommer@openvz.org \
--to=glommer@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=david@fromorbit.com \
--cc=glommer@openvz.org \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=mhocko@suze.cz \
/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).