Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp4723523pxt; Wed, 11 Aug 2021 12:31:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyHS+Nn1+TAJaN9xlWQaaOFAXdMNhbJnW9SichM4wMhrEJBNM0nae/GfOPYC71S/BPq+61W X-Received: by 2002:aa7:ce07:: with SMTP id d7mr600250edv.127.1628710315273; Wed, 11 Aug 2021 12:31:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628710315; cv=none; d=google.com; s=arc-20160816; b=HdpGXzjWjVuWNtLcGZlG3Afi+Jk+UI0Y4jw8svCRVFeQFgYNILFOm/pr8pZ3m4uG8H ZF0zgKEYBdZ/bKvrRHbXAlWcwxwxULR49gA7pqN4R5/fbBRu6Ax50O5g/+XxEohZNDh+ GpVVyFY3U/YJAnI1nuBrDYuolZGY7EIQM7MZqtmvoe4bmr2XhLzYKCDHJrK80WKD/7yH pqXPEsMxNzslBk+2OhpRruaJgaMsmD8MW0l9U8afRC7WbTqQxGx+4U0SHEvp8PlSrcA+ YLIkzaTsCZg4R2P4cXDJO8vxeEQlgc7yhBhyaHn4vSw9WPi0LKXwRifFyOqUL1mgwtCz EhGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:subject:from:dkim-signature; bh=tiwffSXoiH4DxwCpTg6qh9csw8fx7R1FkfmT6DZocnc=; b=YnN2GiZ3aR+e1lG69pUCZ9rRAWJIxn0sOwH8E+fKUG5YGHIe1CNrPtrkKWeMi8VyAX cfz8TT8zA9F125UQ+ta063ow0HUiejhYEn7nCW0KCe0+VjfRPGhXDfWx0Z/qvYPSiwmI 7FpwcWBxMssQe1u4JpUtYXZ2/lafv1OYOsZBPeImTmSvBDmIraT3FbuRDFbs6HOOFnLh NaT7yKn1OI1Us89watQlF6LzZTcezct/iDaeLthsVzS3NZKc2gxICmjOsE0O5NixHXKU FfKN8aO93GXY3fAqANqw/l86/u1RjYWw9uP/caiE08uhngloauhAyu4hTmAwEwDP6OYM x/pw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CyRliTBN; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w13si265303ede.389.2021.08.11.12.31.30; Wed, 11 Aug 2021 12:31:55 -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=@redhat.com header.s=mimecast20190719 header.b=CyRliTBN; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231216AbhHKT1t (ORCPT + 99 others); Wed, 11 Aug 2021 15:27:49 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:56195 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231154AbhHKT1t (ORCPT ); Wed, 11 Aug 2021 15:27:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628710044; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tiwffSXoiH4DxwCpTg6qh9csw8fx7R1FkfmT6DZocnc=; b=CyRliTBNRNsLfXCLTY0EZhKVS21jvL2Auc5Su/LojcjPOGhDuJb8oK8MspIiOaWKGufPHS f395vfpoq1a7DDL7mzKS0xQrRYROn1GXoOvuv8C2jebsJhIIWSxWZKJfFr5hu6hFsGZ//i Utgy7nBiX1XbbKhTFeErpfi+s4xw7ZI= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-563-6dt-1g1JOVuALCq2RqyLrg-1; Wed, 11 Aug 2021 15:27:23 -0400 X-MC-Unique: 6dt-1g1JOVuALCq2RqyLrg-1 Received: by mail-qt1-f197.google.com with SMTP id m8-20020a05622a0548b029028e6910f18aso1873809qtx.4 for ; Wed, 11 Aug 2021 12:27:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=tiwffSXoiH4DxwCpTg6qh9csw8fx7R1FkfmT6DZocnc=; b=KzAKzJ+nSljIFiVaX6xI7eqpoerONcYCnltjPa4ae1yWP+BnAisKpJnz5/1iMB16iu F40FQsGd3aF2H9mTBoVpvn4tfHUKIMiW9lbC9oSX0sBBbg70XumAVts52X7ySLnyYt90 el09rZLPDrJJcYtnxvYTwQCmJ64zDX9f9U5gIGvLCCEQ8zi27pMzg9VauRj0Y4DbPtUC 1kBMR1irRnfe0o6W8rgrXwtNpdw3osLwH+6ks2UNhYMApGTPMlg4mnyR+EmBvbMKh4vq 7X//xryQGAAsQgqbSXZwDa3DwyXJ+q3Sw0D649T4dkXg9bY3ZTwaA0xwu3RsHDhhyNmU bgwQ== X-Gm-Message-State: AOAM531msjtR7n3IxSq+7d/sLjxGsqOQiJhnXQUZgDqolfPbMvCn8ssE BhRRsChjqyHOHuYrB+f+jRlAL7wTzTkGFNhVrTeGnBuyg8Sz9lNx9nL687fZVL/PeiAzJoaj7sZ ZVgX4EGkWv4nZ1m30KwPbJTAE X-Received: by 2002:a05:6214:528a:: with SMTP id kj10mr223844qvb.38.1628710042540; Wed, 11 Aug 2021 12:27:22 -0700 (PDT) X-Received: by 2002:a05:6214:528a:: with SMTP id kj10mr223832qvb.38.1628710042306; Wed, 11 Aug 2021 12:27:22 -0700 (PDT) Received: from llong.remote.csb ([2601:191:8500:76c0::cdbc]) by smtp.gmail.com with ESMTPSA id n11sm45000qkk.93.2021.08.11.12.27.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Aug 2021 12:27:21 -0700 (PDT) From: Waiman Long X-Google-Original-From: Waiman Long Subject: Re: [PATCH v4 2/6] cgroup/cpuset: Properly handle partition root tree To: Tejun Heo 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 , =?UTF-8?Q?Michal_Koutn=c3=bd?= References: <20210811030607.13824-1-longman@redhat.com> <20210811030607.13824-3-longman@redhat.com> Message-ID: Date: Wed, 11 Aug 2021 15:27:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/11/21 2:08 PM, Tejun Heo wrote: > Hello, > > On Tue, Aug 10, 2021 at 11:06:03PM -0400, Waiman Long wrote: >> For a partition root tree with parent and child partition roots, this >> patch will now prohibit changing parent partition root back to member >> as changes to "cpuset.cpus.partition" should not cause those child >> partition roots to become invalid. > So, the general rule is that a descendant should never be able to affect or > restrict what an ancestor can do in terms of configuration. This is because > descendant cgroups can be delegated and a system manager sitting at a higher > level in the hierarchy may not have much control over what happens under > delegated subtrees. > > Given that we're promoting the error state as the first class citizen in the > interface anyway, wouldn't it be better to keep this in line too? Disabling partition at the parent level does invalidate all the child partitions under it. So it must be done with care when we disable a partition. How about we give some indication that a child partition exist when reading cpuset.cpus.partition and recommend double-checking it before disabling a partition? For example, we keep track of the number of cpus delegated to child partitions. Perhaps we can list that information on read. With that information available, I have no objection to allow disabling a parent partition with child partitions under it. Cheers, Longman