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.9 required=5.0 tests=DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,T_DKIM_INVALID 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 213BF7DE79 for ; Tue, 1 May 2018 19:51:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750766AbeEATvx (ORCPT ); Tue, 1 May 2018 15:51:53 -0400 Received: from mail-qk0-f195.google.com ([209.85.220.195]:38259 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750755AbeEATvw (ORCPT ); Tue, 1 May 2018 15:51:52 -0400 Received: by mail-qk0-f195.google.com with SMTP id b39so9604365qkb.5; Tue, 01 May 2018 12:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=oXhQ6JJaPGDHGmHZichdHB9Ey33nTB4yn1y2HibhGBU=; b=Ow/TJ58DR5HsKshg+1IT3tQXgYAk4yXNVIv2OgBZLcrp+8y7R2uTgXl9FmeAhmGSte VfQ0g92cTt6i4IJeH66ZNSRFTQa8Y2at+PQfz+8ncfzWSuw36TrjvJO+bmFinLQG2UJI H+iZJVddvb10dzu9YKmER06WJUQiZYBT+KYeIsLK4pEfrwx6ztM02Z6mpHa1WcifOQrx hhwKaG6Az3LplrNUBLFpHnk5aMYWo/eOjeeP59n4R4edzc8YKCZieDUnAqDQaPWdtrQy iMbhLlWt9ZR283pzU4DeGMzWBoyI77AbPo6AjzkPKVcA9RApYJG/0BeGyVBSmJi3b1Ba IlOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=oXhQ6JJaPGDHGmHZichdHB9Ey33nTB4yn1y2HibhGBU=; b=X+/s63FIM8Hm9r/1nOwS2opa+Mg7ahWpJl/l8dhmn0nPiALdmJVFhfHJqH0AMpb/Vt Efpm/PxPjcRPg0mGY7I98uBhag4GSyCAKcBcvjvIIxF4fxKahb0fkCn07yTCx8zZrLw6 yv2YcHfPpaxM9MteFBhDIgOF8fZW+lZqG/TQoWYhGhEzLuXXH66gxeYUW0UzKaBYyW0g vZ8vUmOjzstRN3r0pc/sIcgqx6O5f40hMshFiCRkqdxyCMLXHCJVDGV9fJSZQxeCuvR8 ndEbdyzFr+kC+NXiLqt/GQjPypl70lL7K2tiQ8RRfQu2tWyEKmov7GKKADoc8z9/AuD2 lmJg== X-Gm-Message-State: ALQs6tAllstM6dG8DEEcokSOnwLAQKWecRQsmK4jzeoc4ySAkiJEG/cm 1mAH0DTOG1LiNroOwCJ9fcE= X-Google-Smtp-Source: AB8JxZpgSU86NgpVViYow+cgNWwFEfdivCWa6jhriA6nWgsXfzY9NPV6+jvqfurzOUaIX10Gf+NtJw== X-Received: by 10.55.31.233 with SMTP id n102mr12887806qkh.385.1525204311000; Tue, 01 May 2018 12:51:51 -0700 (PDT) Received: from localhost ([2620:10d:c091:180::1:8270]) by smtp.gmail.com with ESMTPSA id u24sm8525402qku.18.2018.05.01.12.51.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 12:51:50 -0700 (PDT) Date: Tue, 1 May 2018 12:51:48 -0700 From: Tejun Heo To: Waiman Long Cc: 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 , Juri Lelli Subject: Re: [PATCH v7 4/5] cpuset: Restrict load balancing off cpus to subset of cpus.isolated Message-ID: <20180501195148.GC2368884@devbig577.frc2.facebook.com> References: <1524145624-23655-1-git-send-email-longman@redhat.com> <1524145624-23655-5-git-send-email-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1524145624-23655-5-git-send-email-longman@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Hello, Waiman. Sorry about the delay. On Thu, Apr 19, 2018 at 09:47:03AM -0400, Waiman Long wrote: > With the addition of "cpuset.cpus.isolated", it makes sense to add the > restriction that load balancing can only be turned off if the CPUs in > the isolated cpuset are subset of "cpuset.cpus.isolated". > > Signed-off-by: Waiman Long > --- > Documentation/cgroup-v2.txt | 7 ++++--- > kernel/cgroup/cpuset.c | 29 ++++++++++++++++++++++++++--- > 2 files changed, 30 insertions(+), 6 deletions(-) > > diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt > index 8d89dc2..c4227ee 100644 > --- a/Documentation/cgroup-v2.txt > +++ b/Documentation/cgroup-v2.txt > @@ -1554,9 +1554,10 @@ Cpuset Interface Files > and will not be moved to other CPUs. > > This flag is hierarchical and is inherited by child cpusets. It > - can be turned off only when the CPUs in this cpuset aren't > - listed in the cpuset.cpus of other sibling cgroups, and all > - the child cpusets, if present, have this flag turned off. > + can be explicitly turned off only when it is a direct child of > + the root cgroup and the CPUs in this cpuset are subset of the > + root's "cpuset.cpus.isolated". Moreover, the CPUs cannot be > + listed in the "cpuset.cpus" of other sibling cgroups. It is a little bit convoluted that the isolation requires coordination among root's isolated file and the first-level children's cpus file and the flag. Maybe I'm missing something but can't we do something like the following? * Add isolated flag file, which can only be modified on empty (in terms of cpus) first level children. * Once isolated flag is set, CPUs can only be added to the cpus file iff they aren't being used by anyone else and automatically become isolated. The first level cpus file is owned by the root cgroup anyway, so there's no danger regarding delegation or whatever and the interface would be a lot simpler. Thanks. -- tejun -- 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