Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753042Ab2JPImH (ORCPT ); Tue, 16 Oct 2012 04:42:07 -0400 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:35634 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752650Ab2JPImD (ORCPT ); Tue, 16 Oct 2012 04:42:03 -0400 X-SecurityPolicyCheck: OK by SHieldMailChecker v1.8.4 Message-ID: <507D1DBC.8030805@jp.fujitsu.com> Date: Tue, 16 Oct 2012 17:41:32 +0900 From: Kamezawa Hiroyuki User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Michal Hocko CC: Glauber Costa , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Mel Gorman , Suleiman Souhlal , Tejun Heo , cgroups@vger.kernel.org, Johannes Weiner , Greg Thelen , devel@openvz.org, Frederic Weisbecker , Christoph Lameter , Pekka Enberg Subject: Re: [PATCH v4 09/14] memcg: kmem accounting lifecycle management References: <1349690780-15988-1-git-send-email-glommer@parallels.com> <1349690780-15988-10-git-send-email-glommer@parallels.com> <20121011131143.GF29295@dhcp22.suse.cz> <5077CB05.907@parallels.com> <20121012084100.GE10110@dhcp22.suse.cz> In-Reply-To: <20121012084100.GE10110@dhcp22.suse.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2510 Lines: 64 (2012/10/12 17:41), Michal Hocko wrote: > On Fri 12-10-12 11:47:17, Glauber Costa wrote: >> On 10/11/2012 05:11 PM, Michal Hocko wrote: >>> On Mon 08-10-12 14:06:15, Glauber Costa wrote: >>>> Because kmem charges can outlive the cgroup, we need to make sure that >>>> we won't free the memcg structure while charges are still in flight. >>>> For reviewing simplicity, the charge functions will issue >>>> mem_cgroup_get() at every charge, and mem_cgroup_put() at every >>>> uncharge. >>>> >>>> This can get expensive, however, and we can do better. mem_cgroup_get() >>>> only really needs to be issued once: when the first limit is set. In the >>>> same spirit, we only need to issue mem_cgroup_put() when the last charge >>>> is gone. >>>> >>>> We'll need an extra bit in kmem_accounted for that: KMEM_ACCOUNTED_DEAD. >>>> it will be set when the cgroup dies, if there are charges in the group. >>>> If there aren't, we can proceed right away. >>>> >>>> Our uncharge function will have to test that bit every time the charges >>>> drop to 0. Because that is not the likely output of >>>> res_counter_uncharge, this should not impose a big hit on us: it is >>>> certainly much better than a reference count decrease at every >>>> operation. >>>> >>>> [ v3: merged all lifecycle related patches in one ] >>>> >>>> Signed-off-by: Glauber Costa >>>> CC: Kamezawa Hiroyuki >>>> CC: Christoph Lameter >>>> CC: Pekka Enberg >>>> CC: Michal Hocko >>>> CC: Johannes Weiner >>>> CC: Suleiman Souhlal >>> >>> OK, I like the optimization. I have just one comment to the >>> memcg_kmem_dead naming but other than that >>> >>> Acked-by: Michal Hocko >>> >>> [...] >>>> +static bool memcg_kmem_dead(struct mem_cgroup *memcg) >>> >>> The name is tricky because it doesn't tell you that it clears the flag >>> which made me scratch my head when reading comment in kmem_cgroup_destroy >>> >> memcg_kmem_finally_kill_that_bastard() ? > > memcg_kmem_test_and_clear_dead? I know long but at least clear that the > flag is cleared. Or just open code it. > I agree. Ack by me with that naming. Thanks, -Kame -- 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/