From mboxrd@z Thu Jan 1 00:00:00 1970 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> References: <1373212616-11713-1-git-send-email-glommer@openvz.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 To: linux-mm@kvack.org Return-path: Received: from mail-lb0-f172.google.com ([209.85.217.172]:60950 "EHLO mail-lb0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752744Ab3GGP5h (ORCPT ); Sun, 7 Jul 2013 11:57:37 -0400 In-Reply-To: <1373212616-11713-1-git-send-email-glommer@openvz.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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