Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp499191pxb; Mon, 16 Aug 2021 10:10:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKDdWhkEZFuLH2M6nkqpWD7YaXeKrrzze0MNgiLrz2meKsrtglDPNhsjBkOY7OzqJOZRPn X-Received: by 2002:a6b:7d0c:: with SMTP id c12mr13496914ioq.187.1629133832473; Mon, 16 Aug 2021 10:10:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629133832; cv=none; d=google.com; s=arc-20160816; b=nffDTCq6ONuGLQQFhrgRlGlT5IUGgW/ONdPjI3+w0n7seoZUkt96B4XTSJonAyyj3e 2LMF1q/HDzqn73L4RbpkH5IeOimS8Otcq7eZWf9U0Is/mt6x2GGxVr3WHuLu9mVnW/jy 15irqGO+UyI6GLCNt4KUjNcOOAK/akZzppnpi+Q2KOpk0CYQHhvy4LtAbk4gdVM5pd7h iLltL3C4Ltie0rYc+Zcyho4tBcS5C3PuzWjz1+LsOvM0jbefP81sxVqFpt0KtfdrLG5i 6NHQ9r/qbwj/3X0aV+TSR3QxoDFYJ+M7sUknZFkXzj2PiRbVh2/oR8aGCMNr1PuBb2Fr RIDA== 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=ezzl1wWnIMpMxrnM4W7DDVrnVpy6eCY3TnCdM56lXyY=; b=af/Fq9A48b9nM1hudh9rt8eUtUWczUhaJbVvRp+4gPuwbexrO5kvxLJRKRCufFkDAH ZLH5ifeCbXU9hsiUv+Qr+FHQHN/+fhalNUnnBKLtRmXfQT7VHdQuh5pUYNdhM6m33blt 7eQ11LROGBhcjKTIkZHYE2/BhF9Kqdh2+6WfgXQ7nlAHdV0l9P0nhnM+yqrvTy5ZmJt+ nL2+xoHNCQj3in5XwQPHqCly/A70kjfwNqlTO/5wgky4Ep043ta3TyB4ZAvsdW7mJl15 Pb5qsxIgClqze8sF2ThH0IdMFUN6GJvmEayBKDeC6wdTnatUKb6u2m/ZBcPYkzoxxLWx Veyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bz0Ae35b; 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 m18si13004726jaj.27.2021.08.16.10.10.18; Mon, 16 Aug 2021 10:10:32 -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=bz0Ae35b; 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 S231239AbhHPRJI (ORCPT + 99 others); Mon, 16 Aug 2021 13:09:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229723AbhHPRJG (ORCPT ); Mon, 16 Aug 2021 13:09:06 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 559AFC061764; Mon, 16 Aug 2021 10:08:34 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id om1-20020a17090b3a8100b0017941c44ce4so15189159pjb.3; Mon, 16 Aug 2021 10:08:34 -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=ezzl1wWnIMpMxrnM4W7DDVrnVpy6eCY3TnCdM56lXyY=; b=bz0Ae35bR0EHDskVbOAz6ZJTJsciOg38ggObJYVxbzJbN6FSJ2ga3D1fhPcm3CBqpu 3K137eUco3rmgdvBI9wOWnRzVqJSHdIRWwzQRZVMq9CYCbapAYdanPceAefq2A03pnEk ScQnPxf2oxwtXTyjKIK2YI3gVybmud2L8ktcDPC9qxhthbEbk0zZQlIxeZhSeuwb5oYW 9X2NF47UZc9uMfeoB5Wkg07GZfJzpqJDFJGhSzqy2xMdfwd2JTZXm6fOFfqwndB7PkVO ZXyVbhwHcMWgPdS0q0PU8vFbLywFpxrvVfNCdp9x+byGTE+82sJ4puxpdMTTOxtrG8/d OFdA== 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=ezzl1wWnIMpMxrnM4W7DDVrnVpy6eCY3TnCdM56lXyY=; b=Fxy5dvJq4tNe7bhcGG+PFyDrANErL+Bk2Rzk0HxcGQrtey6TnJE1Xi+X9QtdVIGTMH fSQE4PU4GF7G2YnxYXXgfAvZ5yW7Nt5Clc3fhT+Be7aEGRAfkxrOGABGggW6A64f6cJ8 /EusrF5XL6PxJ1Y2Hk+WhM3Jof78XiKYirBzS6qc9iHsqcdavG35NTPzBbTxZNQ/9Bbd EZn4Zh0el7Siu25f1aqP7Pbk0Kq8kkd4k2cvMFrwxvBJ19INSoeNo3GqW+p5eoAxuEbU I5KnvdfLcnrF9cFuOjW+H3ChNpYdho9WSotpm0zl8vwpcXV3wMLh7g363t4JExK2HOkE bFEg== X-Gm-Message-State: AOAM533IBAjHkACXhJf7qXRjrVRK5LNzq0hl4cxf7n/n7PLs3ZleCAWC /kTgG0Pue6AtzIM+v5Dead0= X-Received: by 2002:a63:f241:: with SMTP id d1mr16821140pgk.424.1629133713651; Mon, 16 Aug 2021 10:08:33 -0700 (PDT) Received: from localhost (2603-800c-1a02-1bae-e24f-43ff-fee6-449f.res6.spectrum.com. [2603:800c:1a02:1bae:e24f:43ff:fee6:449f]) by smtp.gmail.com with ESMTPSA id n23sm13215976pgv.76.2021.08.16.10.08.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Aug 2021 10:08:33 -0700 (PDT) Sender: Tejun Heo Date: Mon, 16 Aug 2021 07:08:31 -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 v6 5/6] cgroup/cpuset: Update description of cpuset.cpus.partition in cgroup-v2.rst Message-ID: References: <20210814205743.3039-1-longman@redhat.com> <20210814205743.3039-6-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210814205743.3039-6-longman@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 14, 2021 at 04:57:42PM -0400, Waiman Long wrote: > + A parent partition may distribute all its CPUs to its child > + partitions as long as it is not the root cgroup and there is no > + task directly associated with that parent partition. Otherwise, "there is not task directly associated with the parent partition" isn't necessary, right? That's already enforced by the cgroup hierarchy itself. > + there must be at least one cpu left in the parent partition. > + A new task cannot be moved to a partition root with no effective > + cpu. > + > + Once becoming a partition root, changes to "cpuset.cpus" > + is generally allowed as long as the first condition above > + (cpu exclusivity rule) is true. All the above ultimately says is that "a new task cannot be moved to a partition root with no effective cpu", but I don't understand why this would be a separate rule. Shouldn't the partition just stop being a partition when it doesn't have any exclusive cpu? What's the benefit of having multiple its own failure mode? > + Sometimes, changes to "cpuset.cpus" or cpu hotplug may cause > + the state of the partition root to become invalid when the > + other constraints of partition root are violated. Therefore, > + it is recommended that users should always set "cpuset.cpus" > + to the proper value first before enabling partition. In case > + "cpuset.cpus" has to be modified after partition is enabled, > + users should check the state of "cpuset.cpus.partition" after > + making change to it to make sure that the partition is still > + valid. So, idk why the this doesn't cover the one above it. Also, this really should be worded a lot stronger. It's not just recommended - confirming and monitoring the transitions is an integral and essential part of using cpuset. ... > + An invalid partition is not a real partition even though the > + restriction of the cpu exclusivity rule will still apply. Is there a reason we can't bring this in line with other failure behaviors? > + In the special case of a parent partition competing with a child > + partition for the only CPU left, the parent partition wins and > + the child partition becomes invalid. Given that parent partitions are *always* empty, this rule doesn't seem to make sense. So, I think this definitely is a step in the right direction but still seems to be neither here or there. Before, we pretended that we could police the input when we couldn't. Now, we're changing the interface so that it includes configuration failures as an integral part; however, we're still policing some particular inputs while letting other inputs pass through and trigger failures and why one is handled one way while the other differently seems rather arbitrary. Thanks. -- tejun