From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755738AbeEaQ2x (ORCPT ); Thu, 31 May 2018 12:28:53 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:58740 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755589AbeEaQ2s (ORCPT ); Thu, 31 May 2018 12:28:48 -0400 Subject: Re: [PATCH] cpuset: Enforce that a child's cpus must be a subset of the parent To: Tejun Heo Cc: Zefan Li , Peter Zijlstra , Johannes Weiner , Ingo Molnar , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kernel-team@fb.com, pjt@google.com, luto@amacapital.net, Mike Galbraith , torvalds@linux-foundation.org, Roman Gushchin , Juri Lelli , Patrick Bellasi References: <1527687991-1431-1-git-send-email-longman@redhat.com> <5B0F4F09.9050100@huawei.com> <5B0FAE72.1090204@huawei.com> <20180531082613.GF12180@hirez.programming.kicks-ass.net> <5B0FB58C.9030705@huawei.com> <4dc718bc-4bd5-4998-853b-9c6ba67b89a0@redhat.com> <20180531155807.GU1351649@devbig577.frc2.facebook.com> From: Waiman Long Organization: Red Hat Message-ID: <9f4ac270-9c56-d616-445d-7021210893f3@redhat.com> Date: Thu, 31 May 2018 12:28:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20180531155807.GU1351649@devbig577.frc2.facebook.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/31/2018 11:58 AM, Tejun Heo wrote: > Hello, > > On Thu, May 31, 2018 at 09:22:23AM -0400, Waiman Long wrote: >>>>>>> As the intersection of g11's cpus and that of g1 is empty, the effective >>>>>>> cpus of g11 is just that of g1. The check in update_cpumask() is now >>>>>>> corrected to make sure that cpus in a child cpus must be a subset of >>>>>>> its parent's cpus. The error "write error: Invalid argument" will now >>>>>>> be reported in the above case. >>>>>>> >>>>>> We made the distinction between user-configured CPUs and effective CPUs >>>>>> in commit 7e88291beefbb758, so actually it's not a bug. >>>>>> >>>>> I remember the original reason is to support restoration of the original >>>>> cpu after cpu offline->online. We use user-configured CPUs to remember >>>>> if the cpu should be restored in the cpuset after it's onlined. >>>> AFAICT you can do that and still have the child a subset of the parent, >>>> no? >>>> . >>> Sure. IIRC this was suggested by Tejun as he had done something similar to devcgroup. >>> >> OK, let wait until Tejun has time to chime in. For me, it just look >> weird to be able to do that. >> >> Another corner case that is not handled is when cpus_allowed is empty. >> In this case, it falls back to the parent's effective cpus. On the other >> hand, it can also be argued that an empty cpus_allowed is a transient >> state and a cpuset shouldn't have cpus undefined while creating children. > Tying together what's configured and what's applied may feel > attractive on the surface but it's a long term headache. > > * It's inconsistent with what other controllers are doing. All the > limit resource configs declare the upper bound the specific cgroup > can consume regardless of what's actually available to it. They > limit but don't guarantee access. > > * Which decouples a given cgroup's configurations from its ancestors', > which allows an ancestor to take away resources that it granted > before and then also giving it back later. No matter what you do, > if you couple configs of cgroup hierarchy, you end up restricting > what an ancestor can do to its sub-hierarchy, which can quickly > become a difficult operational headache. > > So, let's please stay away from it even if that means a bit of > overhead in terms of interface. > > Thanks. > I am fine with that argument. I will update the patch documentation to include this information as I think it is important for the users to be aware of that. Cheers, Longman From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id ABC2F7D043 for ; Thu, 31 May 2018 16:28:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755646AbeEaQ2t (ORCPT ); Thu, 31 May 2018 12:28:49 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:58740 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755589AbeEaQ2s (ORCPT ); Thu, 31 May 2018 12:28:48 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F1B4F76F91; Thu, 31 May 2018 16:28:47 +0000 (UTC) Received: from llong.remote.csb (dhcp-17-81.bos.redhat.com [10.18.17.81]) by smtp.corp.redhat.com (Postfix) with ESMTP id E6070210C6CE; Thu, 31 May 2018 16:28:45 +0000 (UTC) Subject: Re: [PATCH] cpuset: Enforce that a child's cpus must be a subset of the parent To: Tejun Heo Cc: Zefan Li , Peter Zijlstra , Johannes Weiner , Ingo Molnar , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kernel-team@fb.com, pjt@google.com, luto@amacapital.net, Mike Galbraith , torvalds@linux-foundation.org, Roman Gushchin , Juri Lelli , Patrick Bellasi References: <1527687991-1431-1-git-send-email-longman@redhat.com> <5B0F4F09.9050100@huawei.com> <5B0FAE72.1090204@huawei.com> <20180531082613.GF12180@hirez.programming.kicks-ass.net> <5B0FB58C.9030705@huawei.com> <4dc718bc-4bd5-4998-853b-9c6ba67b89a0@redhat.com> <20180531155807.GU1351649@devbig577.frc2.facebook.com> From: Waiman Long Organization: Red Hat Message-ID: <9f4ac270-9c56-d616-445d-7021210893f3@redhat.com> Date: Thu, 31 May 2018 12:28:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20180531155807.GU1351649@devbig577.frc2.facebook.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 31 May 2018 16:28:48 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Thu, 31 May 2018 16:28:48 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'longman@redhat.com' RCPT:'' Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 05/31/2018 11:58 AM, Tejun Heo wrote: > Hello, > > On Thu, May 31, 2018 at 09:22:23AM -0400, Waiman Long wrote: >>>>>>> As the intersection of g11's cpus and that of g1 is empty, the effective >>>>>>> cpus of g11 is just that of g1. The check in update_cpumask() is now >>>>>>> corrected to make sure that cpus in a child cpus must be a subset of >>>>>>> its parent's cpus. The error "write error: Invalid argument" will now >>>>>>> be reported in the above case. >>>>>>> >>>>>> We made the distinction between user-configured CPUs and effective CPUs >>>>>> in commit 7e88291beefbb758, so actually it's not a bug. >>>>>> >>>>> I remember the original reason is to support restoration of the original >>>>> cpu after cpu offline->online. We use user-configured CPUs to remember >>>>> if the cpu should be restored in the cpuset after it's onlined. >>>> AFAICT you can do that and still have the child a subset of the parent, >>>> no? >>>> . >>> Sure. IIRC this was suggested by Tejun as he had done something similar to devcgroup. >>> >> OK, let wait until Tejun has time to chime in. For me, it just look >> weird to be able to do that. >> >> Another corner case that is not handled is when cpus_allowed is empty. >> In this case, it falls back to the parent's effective cpus. On the other >> hand, it can also be argued that an empty cpus_allowed is a transient >> state and a cpuset shouldn't have cpus undefined while creating children. > Tying together what's configured and what's applied may feel > attractive on the surface but it's a long term headache. > > * It's inconsistent with what other controllers are doing. All the > limit resource configs declare the upper bound the specific cgroup > can consume regardless of what's actually available to it. They > limit but don't guarantee access. > > * Which decouples a given cgroup's configurations from its ancestors', > which allows an ancestor to take away resources that it granted > before and then also giving it back later. No matter what you do, > if you couple configs of cgroup hierarchy, you end up restricting > what an ancestor can do to its sub-hierarchy, which can quickly > become a difficult operational headache. > > So, let's please stay away from it even if that means a bit of > overhead in terms of interface. > > Thanks. > I am fine with that argument. I will update the patch documentation to include this information as I think it is important for the users to be aware of that. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html