From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [RFC][PATCH 8/9 v2] cgroup: avoid creating new cgroup under a cgroup being destroyed Date: Fri, 27 Apr 2012 13:40:35 -0700 Message-ID: <20120427204035.GN26595@google.com> References: <4F9A327A.6050409@jp.fujitsu.com> <4F9A36DE.30301@jp.fujitsu.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=PxEpP5/sIKta6/Q2Ejz8EBZ0DmUwNT+0z+d7YFmQzs8=; b=Lfp4DZ3nPg/0XETFyk/f8wfQh5F0aU+JPh+OIu/p6dC5pj6e7Lq5dSJ9r3AZMh/k9/ 53sZD41AHRgaaebB6BsT8qAKqfktQyHek+7sqH3/Q78HApyo3pUV0HjhS9ANYOhtjQec Z5SP1Jr+GnjfS905L9VMBRuLmozxqlAGgGzU86J86rI6HlV/C/7AgVJXFtICaB9kxS+0 ef091nymi3SiJocwqDeq+CgbBefq/KEJWHgFXebbcuMg4+2VZZdD+44t+7zIBIZjtbJE ENapXt0IypFzRKDYLBWEw6NcxXySuuR4drXpxBaD/XhHWdFkXUy3pa1PtJhEke8qYH6s iAtw== Content-Disposition: inline In-Reply-To: <4F9A36DE.30301-+CUm20s59erQFUHtdCDX3A@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: KAMEZAWA Hiroyuki Cc: Linux Kernel , "linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org" , "cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Michal Hocko , Johannes Weiner , Frederic Weisbecker , Glauber Costa , Han Ying , "Aneesh Kumar K.V" , Andrew Morton , kamezawa.hiroyuki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org On Fri, Apr 27, 2012 at 03:04:14PM +0900, KAMEZAWA Hiroyuki wrote: > When ->pre_destroy() is called, it should be guaranteed that > new child cgroup is not created under a cgroup, where pre_destroy() > is running. If not, ->pre_destroy() must check children and > return -EBUSY, which causes warning. > > Signed-off-by: KAMEZAWA Hiroyuki Hmm... I'm getting confused more. Why do we need these cgroup changes at all? cgroup still has cgrp->count check and cgroup_clear_css_refs() after pre_destroy() calls. The order of changes should be, * Make memcg pre_destroy() not fail; however, pre_destroy() should still be ready to be retried. That's the defined interface. * cgroup core updated to drop pre_destroy() retrying and guarantee that pre_destroy() invocation will happen only once. * memcg and other cgroups can update their pre_destroy() if the "won't be retried" part can simplify their implementations. So, there's no reason to be updating cgroup pre_destroy() semantics at this point and these updates actually break cgroup API as it currently stands. The only change necessary is memcg's pre_destroy() not returning zero. Thanks. -- tejun From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx169.postini.com [74.125.245.169]) by kanga.kvack.org (Postfix) with SMTP id 635E26B010A for ; Fri, 27 Apr 2012 16:40:42 -0400 (EDT) Received: by pbcup15 with SMTP id up15so1694749pbc.14 for ; Fri, 27 Apr 2012 13:40:41 -0700 (PDT) Date: Fri, 27 Apr 2012 13:40:35 -0700 From: Tejun Heo Subject: Re: [RFC][PATCH 8/9 v2] cgroup: avoid creating new cgroup under a cgroup being destroyed Message-ID: <20120427204035.GN26595@google.com> References: <4F9A327A.6050409@jp.fujitsu.com> <4F9A36DE.30301@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F9A36DE.30301@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org List-ID: To: KAMEZAWA Hiroyuki Cc: Linux Kernel , "linux-mm@kvack.org" , "cgroups@vger.kernel.org" , Michal Hocko , Johannes Weiner , Frederic Weisbecker , Glauber Costa , Han Ying , "Aneesh Kumar K.V" , Andrew Morton , kamezawa.hiroyuki@gmail.com On Fri, Apr 27, 2012 at 03:04:14PM +0900, KAMEZAWA Hiroyuki wrote: > When ->pre_destroy() is called, it should be guaranteed that > new child cgroup is not created under a cgroup, where pre_destroy() > is running. If not, ->pre_destroy() must check children and > return -EBUSY, which causes warning. > > Signed-off-by: KAMEZAWA Hiroyuki Hmm... I'm getting confused more. Why do we need these cgroup changes at all? cgroup still has cgrp->count check and cgroup_clear_css_refs() after pre_destroy() calls. The order of changes should be, * Make memcg pre_destroy() not fail; however, pre_destroy() should still be ready to be retried. That's the defined interface. * cgroup core updated to drop pre_destroy() retrying and guarantee that pre_destroy() invocation will happen only once. * memcg and other cgroups can update their pre_destroy() if the "won't be retried" part can simplify their implementations. So, there's no reason to be updating cgroup pre_destroy() semantics at this point and these updates actually break cgroup API as it currently stands. The only change necessary is memcg's pre_destroy() not returning zero. 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932158Ab2D0Ukn (ORCPT ); Fri, 27 Apr 2012 16:40:43 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:53415 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751620Ab2D0Ukm (ORCPT ); Fri, 27 Apr 2012 16:40:42 -0400 Date: Fri, 27 Apr 2012 13:40:35 -0700 From: Tejun Heo To: KAMEZAWA Hiroyuki Cc: Linux Kernel , "linux-mm@kvack.org" , "cgroups@vger.kernel.org" , Michal Hocko , Johannes Weiner , Frederic Weisbecker , Glauber Costa , Han Ying , "Aneesh Kumar K.V" , Andrew Morton , kamezawa.hiroyuki@gmail.com Subject: Re: [RFC][PATCH 8/9 v2] cgroup: avoid creating new cgroup under a cgroup being destroyed Message-ID: <20120427204035.GN26595@google.com> References: <4F9A327A.6050409@jp.fujitsu.com> <4F9A36DE.30301@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F9A36DE.30301@jp.fujitsu.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 27, 2012 at 03:04:14PM +0900, KAMEZAWA Hiroyuki wrote: > When ->pre_destroy() is called, it should be guaranteed that > new child cgroup is not created under a cgroup, where pre_destroy() > is running. If not, ->pre_destroy() must check children and > return -EBUSY, which causes warning. > > Signed-off-by: KAMEZAWA Hiroyuki Hmm... I'm getting confused more. Why do we need these cgroup changes at all? cgroup still has cgrp->count check and cgroup_clear_css_refs() after pre_destroy() calls. The order of changes should be, * Make memcg pre_destroy() not fail; however, pre_destroy() should still be ready to be retried. That's the defined interface. * cgroup core updated to drop pre_destroy() retrying and guarantee that pre_destroy() invocation will happen only once. * memcg and other cgroups can update their pre_destroy() if the "won't be retried" part can simplify their implementations. So, there's no reason to be updating cgroup pre_destroy() semantics at this point and these updates actually break cgroup API as it currently stands. The only change necessary is memcg's pre_destroy() not returning zero. Thanks. -- tejun