Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2933200imm; Thu, 24 May 2018 19:20:37 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo198mk/2eGI/WdU+7K/qxUUu+Ac9EMZ8t6Q4vv0XhwG93NP8iS1hu+k5ZI9/IkQFSwcC91 X-Received: by 2002:a17:902:7442:: with SMTP id e2-v6mr566432plt.28.1527214837717; Thu, 24 May 2018 19:20:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527214837; cv=none; d=google.com; s=arc-20160816; b=cwDoFBJtQxMxYv8uAoZ8e5uGoboi5L32l1S//LuFPNUIDrwUs5BT7jMQz/7agrFGdY 0uaglOkHdkoK7Y0eKKVV5A++Pvsb5uVy9MRw6h0T9Et1+9+CkcXbnEEVI5N6EX5XTJX7 CW5p1avfsaaimgR4geSeWduPp+D1oBC5NqlQFS4q14hy54k93Fxv0Zuk6Pbl3tGe5SLz 4luaOBqqmtynZSdj5SUUZBI5jBoKtHo4XuhLADmrmL+LvmBQ2UWqaeMNv/jePg4A/N20 EMn0JvqZi+1FpyzWVRCpgrJ2VBNWkSH7eCsTUkAERhY8efh+FYuvkXXCZWcNKyxq0ccJ AMUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :arc-authentication-results; bh=bA/qw6D4YM89vh15zAQZ2si1pTQV7+Q9kxMuDjW4R6o=; b=X1Cyl/148yukFY8zfsWaSVrRiirwhGvR1jkYBMnm/Z9Y/AP2sX3P1BZ9xpueVqe5wB HFoTdpHYz0LM3X0XxQASNOGpMF8n8F0vER8I+S7C8mSkIdNVJ3pePOZt5aoAmJoPqtj9 46ioxxdHmZMiM6ydXthlQRiOqQA1xVSjwt9ydr2zQsLEKcIq4B1qSzXNmhZIq0I6jfOT E+TBCg/MOJd+TSxUFw8VWEIS5V1rLuZV9VUgI8bsU0oidxNx29UAH2ygdA6UYBKa5tmV TFihGrWsBZwdGXaUMgSX/scwZEisrSQeeq7x3OfTtjLOYFo4dVtUyp01DA8/qim0Fbzt VyBA== 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 q1-v6si22426505plb.549.2018.05.24.19.20.23; Thu, 24 May 2018 19:20:37 -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 S970759AbeEXPJ3 (ORCPT + 99 others); Thu, 24 May 2018 11:09:29 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:57140 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S967928AbeEXPJ0 (ORCPT ); Thu, 24 May 2018 11:09:26 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F1C97406E974; Thu, 24 May 2018 15:09:25 +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 976A7111762D; Thu, 24 May 2018 15:09:22 +0000 (UTC) Subject: Re: [PATCH v8 3/6] cpuset: Add cpuset.sched.load_balance flag to v2 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 References: <1526590545-3350-1-git-send-email-longman@redhat.com> <1526590545-3350-4-git-send-email-longman@redhat.com> <20180524143614.GC3948@localhost.localdomain> From: Waiman Long Organization: Red Hat Message-ID: <4bd31510-4f73-e263-8dc1-5edb0fe63b59@redhat.com> Date: Thu, 24 May 2018 11:09:22 -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: <20180524143614.GC3948@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.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 24 May 2018 15:09:26 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 24 May 2018 15:09:26 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'longman@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/24/2018 10:36 AM, Juri Lelli wrote: > On 17/05/18 16:55, Waiman Long wrote: > > [...] > >> + A parent cgroup cannot distribute all its CPUs to child >> + scheduling domain cgroups unless its load balancing flag is >> + turned off. >> + >> + cpuset.sched.load_balance >> + A read-write single value file which exists on non-root >> + cpuset-enabled cgroups. It is a binary value flag that accepts >> + either "0" (off) or a non-zero value (on). This flag is set >> + by the parent and is not delegatable. >> + >> + When it is on, tasks within this cpuset will be load-balanced >> + by the kernel scheduler. Tasks will be moved from CPUs with >> + high load to other CPUs within the same cpuset with less load >> + periodically. >> + >> + When it is off, there will be no load balancing among CPUs on >> + this cgroup. Tasks will stay in the CPUs they are running on >> + and will not be moved to other CPUs. >> + >> + The initial value of this flag is "1". This flag is then >> + inherited by child cgroups with cpuset enabled. Its state >> + can only be changed on a scheduling domain cgroup with no >> + cpuset-enabled children. > [...] > >> + /* >> + * On default hierachy, a load balance flag change is only allowed >> + * in a scheduling domain with no child cpuset. >> + */ >> + if (cgroup_subsys_on_dfl(cpuset_cgrp_subsys) && balance_flag_changed && >> + (!is_sched_domain(cs) || css_has_online_children(&cs->css))) { >> + err = -EINVAL; >> + goto out; >> + } > The rule is actually > > - no child cpuset > - and it must be a scheduling domain > > Right? Yes, because it doesn't make sense to have a cpu in one cpuset that has loading balance off while, at the same time, in another cpuset with load balancing turned on. This restriction is there to make sure that the above condition will not happen. I may be wrong if there is a realistic use case where the above condition is desired. -Longman