From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4BC7C4338F for ; Wed, 11 Aug 2021 19:27:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB5E460D07 for ; Wed, 11 Aug 2021 19:27:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231366AbhHKT1u (ORCPT ); Wed, 11 Aug 2021 15:27:50 -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-Google-Smtp-Source: ABdhPJxpq/PfA7+2XCpTTT9aRZ2gHbPglInuSLcGqqGbvnQp/UX636wyca1IWuYEvOy4vg/NuCUfRQ== 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