Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3166966pxt; Mon, 9 Aug 2021 19:13:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKam4BJv1Qaygq7ayiPy88gSuy0T5wQkG9jnf9w0knw8ZilVdE0ylgb2b+R/pFYwtbr975 X-Received: by 2002:a02:29c1:: with SMTP id p184mr13962002jap.32.1628561631462; Mon, 09 Aug 2021 19:13:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628561631; cv=none; d=google.com; s=arc-20160816; b=V81f9apDOOJlnKVTA4G6i0yOYZGfTXZzMMwE/oQsv2UqOJhFVQVpWEQXD6KNIr/VA/ QO2StFkU2Z3ERHVfFST8ohSDLuMM6dNDAQXcfObGpXoTEUT60u/d6OjacKLjBsfqw3fg kYUd0BjVS+7zq5e1buJ9b00G0xvsFJ35bFW8pX2BWEgaPUlVMeFPrVrWAS5JsG/tnPkZ 38q0krs1xg8AFOklaXjknGQkJL2WdwFrZp0JQjjBLb+22pO8tEt3lZoUCLBdusoe3T5y WBcfjyeoqhhikItEiXn0qSAGAABTm2X02rBZO6iWRRRBQYKO9qbN2sPM1KNbAT2niHGN k3bA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=XNgzSBl2ViZgrzMacCsKUZKoLxV/azVHoL6Wpcoyx1o=; b=lcX+c9fcxz0MzWV6OzY0KUyN0rMiCu3yJ4q/ohJdyVSFGSPL78JExDf7r0m3QLsva+ ckfIISftO70ZTMR/mLEvIJ5kv5FF11ItCesjXIey67zolwkgU0J8yFATxdgdRYIW1M8l 6J9HOSpPKyBsi2YFUzpQ/IFYMyWABi78qoDNUU/GVMc6xFnaA5ZiM9GM6TQnzQvEEWsj APCcVFySIlLYI9VAQYiQaTER0FGAQWqCGMN+R1zppXgsSzJWhFtKFeuIeFTr69ci/j1i ioCygnoScfmbK5qQkfseqJsf/G0TSXpZVAVx9gw6pwN5sNUm2xu/QZtvx9YatGuyeJQx 69oQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=aEhH+GbM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h3si17647116ila.128.2021.08.09.19.13.39; Mon, 09 Aug 2021 19:13:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=aEhH+GbM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236856AbhHIWrX (ORCPT + 99 others); Mon, 9 Aug 2021 18:47:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235679AbhHIWrW (ORCPT ); Mon, 9 Aug 2021 18:47:22 -0400 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66D97C0613D3; Mon, 9 Aug 2021 15:47:01 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id t3so18290218plg.9; Mon, 09 Aug 2021 15:47:01 -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; bh=XNgzSBl2ViZgrzMacCsKUZKoLxV/azVHoL6Wpcoyx1o=; b=aEhH+GbMzUwYKoNDDFkuXlWKEVtNn+ncfDq/pdkGJJN4UnbE3CmPYayiSuTemIyIyr lZHcTi35GE2BjPN9IB00dF6+Ir6KSDgrQCmP3pcBi4w34uvF+JWOSVOnitMB59NUcNHn IolBa8d9/W36apIoy0H1KpO34GW9m7kGbkT4hpaH4/SwFT52bQk8bc/vpD4DYViw/8RM wR3xDD4TI4UESH3BPx9xBe1a5yt+1l/7X14ojMklyUd91+GtS+/TEBViIswe/IDwYXai tpMJsJJw8HlHXlt10zIKo2l+e889s0F8JMxguiNcQdSJYXN2M05+5urFXjP33WKrLDMc bH/A== 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; bh=XNgzSBl2ViZgrzMacCsKUZKoLxV/azVHoL6Wpcoyx1o=; b=IYYmJFk+A3PHvtsDy6el00O4M3pz9E8AtzehmcoIzDs2OrytSmaJfCj7kPio5mWQUR 3eGt1H8YAVk16bxZJNNl6s22Fq1Fv/m+9DNSJj6T3d5eGEM1mctdnj7ILM2NTm354wti E5ReFVjuRez7LUnM0TRQxuOfpro5Kczo0YdArm5V0IwM0t70pRiUFr7h6Aojyi+aY97v GhtwLxTZMg6ZsbxMNCJ7e9AwNRNrLX4ikoGsH931Qhqz5Dt3Kme+cKyXhEAsTFNybwpG bRBeFElGNz4Qh8BmZuqNeJ5ZoUZjVmZtrX1b0UQAmjrcZL/FdzIRldd/yR9HvzzXGmCH c0yA== X-Gm-Message-State: AOAM531eET7QTYJd19+OBcvvkv50tNiaJx8b/SguTRMCz08Bne8Askfs pty9DRSiBZZGwgqS800ly7hwI0E7XzrTKw== X-Received: by 2002:a65:5083:: with SMTP id r3mr166335pgp.161.1628549220702; Mon, 09 Aug 2021 15:47:00 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:df1c]) by smtp.gmail.com with ESMTPSA id c133sm4203621pfb.174.2021.08.09.15.46.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Aug 2021 15:47:00 -0700 (PDT) Sender: Tejun Heo Date: Mon, 9 Aug 2021 12:46:55 -1000 From: Tejun Heo To: Waiman Long Cc: Zefan Li , Johannes Weiner , Jonathan Corbet , Shuah Khan , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, Andrew Morton , Roman Gushchin , Phil Auld , Peter Zijlstra , Juri Lelli , Frederic Weisbecker , Marcelo Tosatti , Michal =?iso-8859-1?Q?Koutn=FD?= Subject: Re: [PATCH v3 0/9] cgroup/cpuset: Add new cpuset partition type & empty effecitve cpus Message-ID: References: <20210720141834.10624-1-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Waiman. Sorry about the delay. Was off for a while. On Tue, Jul 27, 2021 at 05:14:27PM -0400, Waiman Long wrote: > However, if we have a complicated partition setup with multiple child > partitions. Invalid cpuset.cpus change in a parent partition will cause all > the child partitions to become invalid too. That is the scenario that I > don't want to happen inadvertently. Alternatively, we can restrict those I don't think there's anything fundamentally wrong with it given the requirement that userland has to monitor invalid state transitions. The same mass transition can happen through cpu hotplug operations, right? > invalid changes if a child partition exist and let it pass through and make > it invalid if it is a standalone partition. > > Please let me know which approach do you want me to take. I think it'd be best if we can stick to some principles rather than trying to adjust it for specific scenarios. e.g.: * If a given state can be reached through cpu hot [un]plug, any configuration attempt which reaches the same state should be allowed with the same end result as cpu hot [un]plug. * If a given state can't ever be reached in whichever way, the configuration attempting to reach such state should be rejected. Thanks. -- tejun