Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751880Ab2E3QTW (ORCPT ); Wed, 30 May 2012 12:19:22 -0400 Received: from mx2.parallels.com ([64.131.90.16]:39621 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751128Ab2E3QTV (ORCPT ); Wed, 30 May 2012 12:19:21 -0400 Message-ID: <4FC647FB.90202@parallels.com> Date: Wed, 30 May 2012 20:16:59 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Frederic Weisbecker CC: , , , , Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , , David Rientjes , Christoph Lameter , "Pekka Enberg" Subject: Re: [PATCH v3 16/28] memcg: kmem controller charge/uncharge infrastructure References: <1337951028-3427-1-git-send-email-glommer@parallels.com> <1337951028-3427-17-git-send-email-glommer@parallels.com> <20120530130416.GD25094@somewhere.redhat.com> <4FC61B4E.2060206@parallels.com> <20120530133736.GF25094@somewhere.redhat.com> <4FC622B5.9080600@parallels.com> <20120530135319.GG25094@somewhere.redhat.com> <4FC626DA.3030408@parallels.com> <20120530153256.GA27008@somewhere.redhat.com> In-Reply-To: <20120530153256.GA27008@somewhere.redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [188.255.67.70] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1859 Lines: 40 On 05/30/2012 07:33 PM, Frederic Weisbecker wrote: > On Wed, May 30, 2012 at 05:55:38PM +0400, Glauber Costa wrote: >> On 05/30/2012 05:53 PM, Frederic Weisbecker wrote: >>> On Wed, May 30, 2012 at 05:37:57PM +0400, Glauber Costa wrote: >>>> On 05/30/2012 05:37 PM, Frederic Weisbecker wrote: >>>>> Right. __mem_cgroup_get_kmem_cache() fetches the memcg of the owner >>>>> and calls memcg_create_cache_enqueue() which does css_tryget(&memcg->css). >>>>> After this tryget I think you're fine. And in-between you're safe against >>>>> css_set removal due to rcu_read_lock(). >>>>> >>>>> I'm less clear with __mem_cgroup_new_kmem_page() though... >>>> >>>> That one does not get memcg->css but it does call mem_cgroup_get(), >>>> that does prevent against the memcg structure being freed, which I >>>> believe to be good enough. >>> >>> What if the owner calls cgroup_exit() between mem_cgroup_from_task() >>> and mem_cgroup_get()? The css_set which contains the memcg gets freed. >>> Also the reference on the memcg doesn't even prevent the css_set to >>> be removed, does it? >> It doesn't, but we don't really care. The css can go away, if the >> memcg structure stays. > > Ah right, the memcg itself is only freed at destroy time. > >> The caches will outlive the memcg anyway, >> since it is possible that you delete it, with some caches still >> holding objects that >> are not freed (they will be marked as dead). > > I guess I need to look at how the destroy path is handled in your patchset > then. Or how you ensure that __mem_cgroup_new_kmem_page() can't race against > destroy. Appreciate that, thanks. -- 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/