From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx163.postini.com [74.125.245.163]) by kanga.kvack.org (Postfix) with SMTP id 55BA06B0070 for ; Sun, 7 Jul 2013 11:57:37 -0400 (EDT) Received: by mail-lb0-f172.google.com with SMTP id v20so3152152lbc.17 for ; Sun, 07 Jul 2013 08:57:35 -0700 (PDT) From: Glauber Costa Subject: [PATCH v10 16/16] memcg: flush memcg items upon memcg destruction Date: Sun, 7 Jul 2013 11:56:56 -0400 Message-Id: <1373212616-11713-17-git-send-email-glommer@openvz.org> In-Reply-To: <1373212616-11713-1-git-send-email-glommer@openvz.org> References: <1373212616-11713-1-git-send-email-glommer@openvz.org> Sender: owner-linux-mm@kvack.org List-ID: 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 , Michal Hocko 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 Cc: Mel Gorman Cc: Johannes Weiner Cc: Michal Hocko Cc: Hugh Dickins Cc: Kamezawa Hiroyuki --- mm/memcontrol.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index e2dc89c..90173bc 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -6310,10 +6310,27 @@ static int memcg_init_kmem(struct mem_cgroup *memcg, struct cgroup_subsys *ss) static void kmem_cgroup_css_offline(struct mem_cgroup *memcg) { + int ret; if (!memcg_kmem_is_active(memcg)) return; /* + * 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.8.2.1 -- 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: email@kvack.org