Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp365573imm; Thu, 31 May 2018 01:42:26 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJxYpU0DZDxrQVbnrvi+CoSu0MdjgEsZwcU9MiEhZCaW1qrIacPmlDCAghRSuKfy9gSXI/5 X-Received: by 2002:a62:a21e:: with SMTP id m30-v6mr6023837pff.251.1527756146091; Thu, 31 May 2018 01:42:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527756146; cv=none; d=google.com; s=arc-20160816; b=K6GLO57G58FsWRR+mJ6ciY1oGnf8Lri4uYuKumdPiQ75v9/mFDrBtRdxXDL82K9Dbi 51d/JMWDMG0rLeMSQMBT4zstCWjlk+QHKQWpUvipv+4oc+smNaDhIw3OWdg6o1doK/2Z mYvBUUH7AIYjeILHG+aZZjYJZEBSV3xcTaNJkjf2/J1ukhQE/+IyAri+0Vi+Kcswkksn LgMAai0gqswj0GxdBT7D77MzBmhw/3DKpAt6TFw4UsWKBcfMGSu7e5ziUSDJXmsCDVai O3TDB82WGSiEZSPdzEZ6MtHqwYu4pZnRKAoIQKgyZNI1VhFJjdEho9Ljhi5MiUfGV9Zq ZlSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=UKvWDWHgVQ2AfQOJHBwGA0BOP/lGvXy7MSRlSb+NqFg=; b=jtLHfwsmZYiQTUeaggFZRnl56sq4fTbAaPQp2V0U66xsUMueH53jo82SOTrbHZe9Qh Tu41NxnisLiK9SHFpVZyUeYrFanyNafE9gAHdChU8/CQErq6hs/gczaWlAI7RKF3nbef Gx/xj3Fcj2d8xnYF9K1nome5i5+e9eFats4EJ1dUt3witThMge11dPPb8c0Sw3TEbb03 nokTl7B0KsBHNej/GEOaim3Ca3KEHMRWJa99cGFbN2rSdXIniCDmystE3Y7cXYptTJtN Gb+o/9jMTJl0t/8JZGJCtuEkAkdOtQtgx7bx8Yfm3JjNhAOglVk/yBM01gPKqDV71Jwf ds/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d15-v6si15695957pgu.21.2018.05.31.01.42.11; Thu, 31 May 2018 01:42:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754105AbeEaIlp (ORCPT + 99 others); Thu, 31 May 2018 04:41:45 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:41745 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754046AbeEaIlj (ORCPT ); Thu, 31 May 2018 04:41:39 -0400 Received: by mail-wr0-f193.google.com with SMTP id u12-v6so32099365wrn.8 for ; Thu, 31 May 2018 01:41:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=UKvWDWHgVQ2AfQOJHBwGA0BOP/lGvXy7MSRlSb+NqFg=; b=piCiXUDONve4KDvEdB9CcdE33jqSClnnNLPiakQp0cUlDz659ZRaBwVWQd3E0seeDl laskhM71KsfOqmJ9NZMM486saJgKPpDp+e1liY++IKn0+09DW+ZblwpZKdw5kn+rT4Oe ay2oh7xQcfywynJH+n58dpTYDBZJOZ78q/8+8Y27mH0jVCslapaqjPgSwJd+UCrB7qrh g+jdPfFk68+r0AOKSJ/M+QvskriUgghB4C7+QAZxP4vI7r88tReDQskxpOs/WUpN4Q8z jS4Ug6OvzfoOVsmH4AKrPHk4fYzG0dS8wF4a7aNNYDRUPUfMa+ayEapyevvzyjSVuWF2 2ZwA== X-Gm-Message-State: ALKqPwefpfxO0eySWkffAhfJ1jAl/L72I8Re/DLUoc5rWaxQ1Anbxj3Z SwCnnxGmwBofvnptvqDtUImxaw== X-Received: by 2002:adf:a690:: with SMTP id t16-v6mr4712589wrc.1.1527756098064; Thu, 31 May 2018 01:41:38 -0700 (PDT) Received: from localhost.localdomain ([151.15.207.242]) by smtp.gmail.com with ESMTPSA id v15-v6sm564039wmf.47.2018.05.31.01.41.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 31 May 2018 01:41:37 -0700 (PDT) Date: Thu, 31 May 2018 10:41:34 +0200 From: Juri Lelli To: Peter Zijlstra Cc: Zefan Li , Waiman Long , Tejun Heo , 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 , Patrick Bellasi Subject: Re: [PATCH] cpuset: Enforce that a child's cpus must be a subset of the parent Message-ID: <20180531084134.GA17937@localhost.localdomain> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180531082613.GF12180@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 31/05/18 10:26, Peter Zijlstra wrote: > On Thu, May 31, 2018 at 04:12:34PM +0800, Zefan Li wrote: > > On 2018/5/31 9:25, Zefan Li wrote: > > > Hi Waiman, > > > > > > On 2018/5/30 21:46, Waiman Long wrote: > > >> It was found that the cpuset.cpus could contain CPUs that are not listed > > >> in their parent's cpu list as shown by the command sequence below: > > >> > > >> # echo "+cpuset" >cgroup.subtree_control > > >> # mkdir g1 > > >> # echo 0-5 >g1/cpuset.cpus > > >> # mkdir g1/g11 > > >> # echo "+cpuset" > g1/cgroup.subtree_control > > >> # echo 6-11 >g1/g11/cpuset.cpus > > >> # grep -R . g1 | grep "\.cpus" > > >> g1/cpuset.cpus:0-5 > > >> g1/cpuset.cpus.effective:0-5 > > >> g1/g11/cpuset.cpus:6-11 > > >> g1/g11/cpuset.cpus.effective:0-5 > > >> > > >> 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? Plus this is not hotplug, but a user decision. It could make sense to keep .cpus unmodified after hotplug events, but does it make sense to let the user be able to choose cpus outside the parent domain?