From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753182AbeE3M4P (ORCPT ); Wed, 30 May 2018 08:56:15 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:39428 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753129AbeE3M4N (ORCPT ); Wed, 30 May 2018 08:56:13 -0400 Subject: Re: [PATCH v9 0/7] Enable cpuset controller in default hierarchy To: Juri Lelli Cc: Tejun Heo , Li Zefan , Johannes Weiner , Peter Zijlstra , 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 , Patrick Bellasi References: <1527601294-3444-1-git-send-email-longman@redhat.com> <20180530101317.GB3320@localhost.localdomain> From: Waiman Long Organization: Red Hat Message-ID: Date: Wed, 30 May 2018 08:56:10 -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: <20180530101317.GB3320@localhost.localdomain> 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/30/2018 06:13 AM, Juri Lelli wrote: > Hi, > > On 29/05/18 09:41, Waiman Long wrote: >> v9: >> - Rename cpuset.sched.domain to cpuset.sched.domain_root to better >> identify its purpose as the root of a new scheduling domain or >> partition. >> - Clarify in the document about the purpose of domain_root and >> load_balance. Using domain_root is th only way to create new >> partition. >> - Fix a lockdep warning in update_isolated_cpumask() function. >> - Add a new patch to eliminate call to generate_sched_domains() for >> v2 when a change in cpu list does not touch a domain_root. > I was playing with this and ended up with the situation below: > > g1/cgroup.controllers:cpuset > g1/cgroup.events:populated 0 > g1/cgroup.max.depth:max > g1/cgroup.max.descendants:max > g1/cgroup.stat:nr_descendants 1 > g1/cgroup.stat:nr_dying_descendants 0 > g1/cgroup.subtree_control:cpuset > g1/cgroup.type:domain > g1/cpuset.cpus:0-5 <--- > g1/cpuset.cpus.effective:0-5 > g1/cpuset.mems.effective:0-1 > g1/cpuset.sched.domain_root:1 <--- > g1/cpuset.sched.load_balance:1 > g1/cpu.stat:usage_usec 0 > g1/cpu.stat:user_usec 0 > g1/cpu.stat:system_usec 0 > g1/g11/cgroup.events:populated 0 > g1/g11/cgroup.max.descendants:max > g1/g11/cpu.stat:usage_usec 0 > g1/g11/cpu.stat:user_usec 0 > g1/g11/cpu.stat:system_usec 0 > g1/g11/cgroup.type:domain > g1/g11/cgroup.stat:nr_descendants 0 > g1/g11/cgroup.stat:nr_dying_descendants 0 > g1/g11/cpuset.cpus.effective:0-5 > g1/g11/cgroup.controllers:cpuset > g1/g11/cpuset.sched.load_balance:1 > g1/g11/cpuset.mems.effective:0-1 > g1/g11/cpuset.cpus:6-11 <--- > g1/g11/cgroup.max.depth:max > g1/g11/cpuset.sched.domain_root:0 > > Should this be allowed? I was expecting subgroup g11 should be > restricted to a subset of g1's cpus. > > Best, > > - Juri That shouldn't be allowed.The code is probably missing some checks that should have been done. What was the sequence of commands leading to the above configuration? 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 2B19F7D072 for ; Wed, 30 May 2018 12:56:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753141AbeE3M4O (ORCPT ); Wed, 30 May 2018 08:56:14 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:39428 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753129AbeE3M4N (ORCPT ); Wed, 30 May 2018 08:56:13 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6AE3C401EF0E; Wed, 30 May 2018 12:56:12 +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 BEDFD217B409; Wed, 30 May 2018 12:56:10 +0000 (UTC) Subject: Re: [PATCH v9 0/7] Enable cpuset controller in default hierarchy To: Juri Lelli Cc: Tejun Heo , Li Zefan , Johannes Weiner , Peter Zijlstra , 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 , Patrick Bellasi References: <1527601294-3444-1-git-send-email-longman@redhat.com> <20180530101317.GB3320@localhost.localdomain> From: Waiman Long Organization: Red Hat Message-ID: Date: Wed, 30 May 2018 08:56:10 -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: <20180530101317.GB3320@localhost.localdomain> 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.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 30 May 2018 12:56:12 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 30 May 2018 12:56:12 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.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/30/2018 06:13 AM, Juri Lelli wrote: > Hi, > > On 29/05/18 09:41, Waiman Long wrote: >> v9: >> - Rename cpuset.sched.domain to cpuset.sched.domain_root to better >> identify its purpose as the root of a new scheduling domain or >> partition. >> - Clarify in the document about the purpose of domain_root and >> load_balance. Using domain_root is th only way to create new >> partition. >> - Fix a lockdep warning in update_isolated_cpumask() function. >> - Add a new patch to eliminate call to generate_sched_domains() for >> v2 when a change in cpu list does not touch a domain_root. > I was playing with this and ended up with the situation below: > > g1/cgroup.controllers:cpuset > g1/cgroup.events:populated 0 > g1/cgroup.max.depth:max > g1/cgroup.max.descendants:max > g1/cgroup.stat:nr_descendants 1 > g1/cgroup.stat:nr_dying_descendants 0 > g1/cgroup.subtree_control:cpuset > g1/cgroup.type:domain > g1/cpuset.cpus:0-5 <--- > g1/cpuset.cpus.effective:0-5 > g1/cpuset.mems.effective:0-1 > g1/cpuset.sched.domain_root:1 <--- > g1/cpuset.sched.load_balance:1 > g1/cpu.stat:usage_usec 0 > g1/cpu.stat:user_usec 0 > g1/cpu.stat:system_usec 0 > g1/g11/cgroup.events:populated 0 > g1/g11/cgroup.max.descendants:max > g1/g11/cpu.stat:usage_usec 0 > g1/g11/cpu.stat:user_usec 0 > g1/g11/cpu.stat:system_usec 0 > g1/g11/cgroup.type:domain > g1/g11/cgroup.stat:nr_descendants 0 > g1/g11/cgroup.stat:nr_dying_descendants 0 > g1/g11/cpuset.cpus.effective:0-5 > g1/g11/cgroup.controllers:cpuset > g1/g11/cpuset.sched.load_balance:1 > g1/g11/cpuset.mems.effective:0-1 > g1/g11/cpuset.cpus:6-11 <--- > g1/g11/cgroup.max.depth:max > g1/g11/cpuset.sched.domain_root:0 > > Should this be allowed? I was expecting subgroup g11 should be > restricted to a subset of g1's cpus. > > Best, > > - Juri That shouldn't be allowed.The code is probably missing some checks that should have been done. What was the sequence of commands leading to the above configuration? 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