From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx139.postini.com [74.125.245.139]) by kanga.kvack.org (Postfix) with SMTP id 526E96B005A for ; Wed, 27 Jun 2012 13:58:23 -0400 (EDT) Received: by pbbrp2 with SMTP id rp2so2314805pbb.14 for ; Wed, 27 Jun 2012 10:58:22 -0700 (PDT) Date: Wed, 27 Jun 2012 10:58:18 -0700 From: Tejun Heo Subject: Re: [PATCH v3][0/6] memcg: prevent -ENOMEM in pre_destroy() Message-ID: <20120627175818.GM15811@google.com> References: <4FACDED0.3020400@jp.fujitsu.com> <20120621202043.GD4642@google.com> <4FE3ADDD.9060908@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FE3ADDD.9060908@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org List-ID: To: Kamezawa Hiroyuki Cc: "linux-mm@kvack.org" , "cgroups@vger.kernel.org" , Michal Hocko , Johannes Weiner , Frederic Weisbecker , Han Ying , Glauber Costa , "Aneesh Kumar K.V" , Andrew Morton , Hiroyuki Kamezawa , Linux Kernel Hello, KAME. On Fri, Jun 22, 2012 at 08:27:25AM +0900, Kamezawa Hiroyuki wrote: > Remaining 20% of work is based on a modification to cgroup layer > > How do you think this patch ? (This patch is not tested yet...so > may have troubles...) I think callers of pre_destory() is not so many... > > == > From a28db946f91f3509d25779e8c5db249506cc4b07 Mon Sep 17 00:00:00 2001 > From: KAMEZAWA Hiroyuki > Date: Fri, 22 Jun 2012 08:38:38 +0900 > Subject: [PATCH] cgroup: keep cgroup_mutex() while calling ->pre_destroy() > > In past, memcg's pre_destroy() was verrry slow because of the possibility > of page reclaiming in it. So, cgroup_mutex() was released before calling > pre_destroy() callbacks. Now, it's enough fast. memcg just scans the list > and move pages to other cgroup, no memory reclaim happens. > Then, we can keep cgroup_mutex() there. > > By holding looks, we can avoid following cases > 1. new task is attached while rmdir(). > 2. new child cgroup is created while rmdir() > 3. new task is attached to cgroup and removed from cgroup before > checking css's count. So, ->destroy() will be called even if > some trashes by the task remains > > (3. is terrible case...even if I think it will not happen in real world..) Ooh, once memcg drops the __DEPRECATED_clear_css_refs, cgroup_rmdir() will mark the cgroup dead before start calling pre_destroy() and none of the above will happen. Thanks. -- tejun -- 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