From: Glauber Costa <glom...@openvz.org>

When a memcg is destroyed, it won't be imediately released until all
objects are gone. This means that if a memcg is restarted with the very
same workload - a very common case, the objects already cached won't be
billed to the new memcg. This is mostly undesirable since a container
can exploit this by restarting itself every time it reaches its limit,
and then coming up again with a fresh new limit.

Since now we have targeted reclaim, I sustain that we should assume that
a memcg that is destroyed should be flushed away. It makes perfect sense
if we assume that a memcg that goes away most likely indicates an
isolated workload that is terminated.

Signed-off-by: Glauber Costa <glom...@openvz.org>
Signed-off-by: Vladimir Davydov <vdavy...@parallels.com>
Cc: Johannes Weiner <han...@cmpxchg.org>
Cc: Michal Hocko <mho...@suse.cz>
Cc: Balbir Singh <bsinghar...@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hir...@jp.fujitsu.com>
---
 mm/memcontrol.c |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 72db892..e780511 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6452,12 +6452,29 @@ static void memcg_destroy_kmem(struct mem_cgroup *memcg)
 
 static void kmem_cgroup_css_offline(struct mem_cgroup *memcg)
 {
+       int ret;
        if (!memcg_kmem_is_active(memcg))
                return;
 
        cancel_work_sync(&memcg->kmem_shrink_work);
 
        /*
+        * When a memcg is destroyed, it won't be imediately released until all
+        * objects are gone. This means that if a memcg is restarted with the
+        * very same workload - a very common case, the objects already cached
+        * won't be billed to the new memcg. This is mostly undesirable since a
+        * container can exploit this by restarting itself every time it
+        * reaches its limit, and then coming up again with a fresh new limit.
+        *
+        * Therefore a memcg that is destroyed should be flushed away. It makes
+        * perfect sense if we assume that a memcg that goes away indicates an
+        * isolated workload that is terminated.
+        */
+       do {
+               ret = try_to_free_mem_cgroup_kmem(memcg, GFP_KERNEL);
+       } while (ret);
+
+       /*
         * kmem charges can outlive the cgroup. In the case of slab
         * pages, for instance, a page contain objects from various
         * processes. As we prevent from taking a reference for every
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to