Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758442Ab2FZHYJ (ORCPT ); Tue, 26 Jun 2012 03:24:09 -0400 Received: from mx2.parallels.com ([64.131.90.16]:35650 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758316Ab2FZHYH (ORCPT ); Tue, 26 Jun 2012 03:24:07 -0400 Message-ID: <4FE962F2.2050701@parallels.com> Date: Tue, 26 Jun 2012 11:21:22 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Kamezawa Hiroyuki CC: , , Andrew Morton , , Frederic Weisbecker , David Rientjes , Pekka Enberg , Michal Hocko , Johannes Weiner , Christoph Lameter , , Tejun Heo , Pekka Enberg , Suleiman Souhlal Subject: Re: [PATCH 10/11] memcg: allow a memcg with kmem charges to be destructed. References: <1340633728-12785-1-git-send-email-glommer@parallels.com> <1340633728-12785-11-git-send-email-glommer@parallels.com> <4FE94FDC.7070105@jp.fujitsu.com> In-Reply-To: <4FE94FDC.7070105@jp.fujitsu.com> Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Originating-IP: [109.173.9.3] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2806 Lines: 73 On 06/26/2012 09:59 AM, Kamezawa Hiroyuki wrote: > (2012/06/25 23:15), Glauber Costa wrote: >> Because the ultimate goal of the kmem tracking in memcg is to >> track slab pages as well, we can't guarantee that we'll always >> be able to point a page to a particular process, and migrate >> the charges along with it - since in the common case, a page >> will contain data belonging to multiple processes. >> >> Because of that, when we destroy a memcg, we only make sure >> the destruction will succeed by discounting the kmem charges >> from the user charges when we try to empty the cgroup. >> >> Signed-off-by: Glauber Costa >> CC: Christoph Lameter >> CC: Pekka Enberg >> CC: Michal Hocko >> CC: Kamezawa Hiroyuki >> CC: Johannes Weiner >> CC: Suleiman Souhlal >> --- >> mm/memcontrol.c | 10 +++++++++- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index a6a440b..bb9b6fe 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -598,6 +598,11 @@ static void disarm_kmem_keys(struct mem_cgroup *memcg) >> { >> if (test_bit(KMEM_ACCOUNTED_THIS, &memcg->kmem_accounted)) >> static_key_slow_dec(&mem_cgroup_kmem_enabled_key); >> + /* >> + * This check can't live in kmem destruction function, >> + * since the charges will outlive the cgroup >> + */ >> + BUG_ON(res_counter_read_u64(&memcg->kmem, RES_USAGE) != 0); >> } >> #else >> static void disarm_kmem_keys(struct mem_cgroup *memcg) >> @@ -3838,6 +3843,7 @@ static int mem_cgroup_force_empty(struct mem_cgroup *memcg, bool free_all) >> int node, zid, shrink; >> int nr_retries = MEM_CGROUP_RECLAIM_RETRIES; >> struct cgroup *cgrp = memcg->css.cgroup; >> + u64 usage; >> >> css_get(&memcg->css); >> >> @@ -3877,8 +3883,10 @@ move_account: >> if (ret == -ENOMEM) >> goto try_to_free; >> cond_resched(); >> + usage = res_counter_read_u64(&memcg->res, RES_USAGE) - >> + res_counter_read_u64(&memcg->kmem, RES_USAGE); >> /* "ret" should also be checked to ensure all lists are empty. */ >> - } while (res_counter_read_u64(&memcg->res, RES_USAGE) > 0 || ret); >> + } while (usage > 0 || ret); >> out: >> css_put(&memcg->css); >> return ret; >> > Hm....maybe work enough. Could you add more comments on the code ? > > Acked-by: KAMEZAWA Hiroyuki > I always can. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/