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 8F7B3C4338F for ; Thu, 12 Aug 2021 22:56:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 66F9E6103E for ; Thu, 12 Aug 2021 22:56:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238438AbhHLW4c (ORCPT ); Thu, 12 Aug 2021 18:56:32 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:31733 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238417AbhHLW4b (ORCPT ); Thu, 12 Aug 2021 18:56:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628808965; 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=pU1jcFqEFviufW4xVur65db047ti+YmuGAqH7xi6AYA=; b=F227wH2m+WktspAsKmf9g5iISMBbhkgJk/S9wl769RyyzK3XLbYoL+9+2TlJz2LkPOxHgj Ac5CMoVLjRDuT7UB912h4ss4hPEXrDp00nuwYlVhyqUf6Y19fKoYv4+SPyyWw//gwFOl8n +9sR3lH2AV0ccURNa2pwU8gTpWbneFI= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-512-gGgvOlu2P_GtcH1P_G976g-1; Thu, 12 Aug 2021 18:56:03 -0400 X-MC-Unique: gGgvOlu2P_GtcH1P_G976g-1 Received: by mail-qt1-f200.google.com with SMTP id e3-20020ac80b030000b029028ac1c46c2aso4096883qti.2 for ; Thu, 12 Aug 2021 15:56:03 -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=pU1jcFqEFviufW4xVur65db047ti+YmuGAqH7xi6AYA=; b=O5XqgU99ECY87W/kTJ3JX/gNaCp3mYJhZLuvtttywmo2ozhxTJjPIWKhEwZUzLEsAl /BgXUZgp+OY7/zOgtaECQ3OsBvSJM1nRkbE1NE7Ih9RDPfNT9d4Ranz81MCy3WsWql/O 3SNGu/8Vbunwuo3J3GNybp9a2wgoOQmSoI24inyvJSEhZXq8ivauF1Vm5J5xdMNeo6yP djpM+/zsgXR1Hci8WlTRC8N5bx1HvW5qTVf0digzt3sJrj7M7R2nu6EBDhUIcv5XBeQP l0Y5ecGLS0klbgIDhX0G4nF+V3g+I2+5HPf8Odhnf3wgK9X9pRZc/V15Kxs/Kp/ns0gK w0qg== X-Gm-Message-State: AOAM533vuNQsX09vBcajtROXGk8vpwdryLb+HxvdbmOzFjkC5/nELo0w EJ9jBefhZHXwZT1+7kSINlcFRpTR7UpCVUPr8njh2e3Uk35YvJmhn/eGzjb8tgatiI899NjoDuc IreJh7VBnEGf8MYZp/ALutaKo X-Received: by 2002:a05:6214:a02:: with SMTP id dw2mr6395574qvb.61.1628808963313; Thu, 12 Aug 2021 15:56:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz420Kic49s06UtdxHWo/YD/3XASGNT0TOXMTVd4tfATpr0sLrT6MWjhl7rS+FEPDfsmmSwtA== X-Received: by 2002:a05:6214:a02:: with SMTP id dw2mr6395557qvb.61.1628808963138; Thu, 12 Aug 2021 15:56:03 -0700 (PDT) Received: from llong.remote.csb ([2601:191:8500:76c0::cdbc]) by smtp.gmail.com with ESMTPSA id q9sm2220931qkn.85.2021.08.12.15.56.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Aug 2021 15:56:02 -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 , 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 , =?UTF-8?Q?Michal_Koutn=c3=bd?= References: <20210811030607.13824-1-longman@redhat.com> <20210811030607.13824-3-longman@redhat.com> Message-ID: <55f61b66-5159-7e13-6e41-33df042612b0@redhat.com> Date: Thu, 12 Aug 2021 18:56:00 -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: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/12/21 6:18 PM, Tejun Heo wrote: > Hello, > > On Wed, Aug 11, 2021 at 03:27:20PM -0400, Waiman Long wrote: >> 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. > This is a general problem which has always existed regardless of whether the > errors are synchronous or not. There are many different reasons that a write > to a cpuset interface file could fail and it has never been easy to tell why > a given operation was rejected. Making error notifications asynchronous > doesn't really change anything fundamental although it does make the > situation a bit more opaque. > > I'm all for improving visibility. Now that we can consolidate most error > states into a unified failure state, this might actually be easier to do. > IOW, we now just have to explain why a given cgroup is in an invalid state > rather than additionally having to explain why a given write has been > rejected, which is pretty awkward to do as those failures are transient and > local to the writer. > > So, if you wanna tackle this, let's do it right and provide something > comprehensive rather than explaining just one failure. That sounds reasonable. My current idea is to add invalid partition reason string to cpuset. So when users read cpuset.cpus.partition of an invalid partition, it will read something like "root invalid  ()". What do you think? Cheers, Longman From mboxrd@z Thu Jan 1 00:00:00 1970 From: Waiman Long Subject: Re: [PATCH v4 2/6] cgroup/cpuset: Properly handle partition root tree Date: Thu, 12 Aug 2021 18:56:00 -0400 Message-ID: <55f61b66-5159-7e13-6e41-33df042612b0@redhat.com> References: <20210811030607.13824-1-longman@redhat.com> <20210811030607.13824-3-longman@redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628808965; 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=pU1jcFqEFviufW4xVur65db047ti+YmuGAqH7xi6AYA=; b=F227wH2m+WktspAsKmf9g5iISMBbhkgJk/S9wl769RyyzK3XLbYoL+9+2TlJz2LkPOxHgj Ac5CMoVLjRDuT7UB912h4ss4hPEXrDp00nuwYlVhyqUf6Y19fKoYv4+SPyyWw//gwFOl8n +9sR3lH2AV0ccURNa2pwU8gTpWbneFI= In-Reply-To: Content-Language: en-US List-ID: Content-Type: text/plain; charset="iso-8859-9"; format="flowed" To: Tejun Heo , 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 , =?UTF-8?Q?Michal_Koutn=c3=bd?= On 8/12/21 6:18 PM, Tejun Heo wrote: > Hello, > > On Wed, Aug 11, 2021 at 03:27:20PM -0400, Waiman Long wrote: >> 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 read= ing >> 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. > This is a general problem which has always existed regardless of whether = the > errors are synchronous or not. There are many different reasons that a wr= ite > to a cpuset interface file could fail and it has never been easy to tell = why > a given operation was rejected. Making error notifications asynchronous > doesn't really change anything fundamental although it does make the > situation a bit more opaque. > > I'm all for improving visibility. Now that we can consolidate most error > states into a unified failure state, this might actually be easier to do. > IOW, we now just have to explain why a given cgroup is in an invalid state > rather than additionally having to explain why a given write has been > rejected, which is pretty awkward to do as those failures are transient a= nd > local to the writer. > > So, if you wanna tackle this, let's do it right and provide something > comprehensive rather than explaining just one failure. That sounds reasonable. My current idea is to add invalid partition=20 reason string to cpuset. So when users read cpuset.cpus.partition of an=20 invalid partition, it will read something like "root invalid=C2=A0 ()". What do you think? Cheers, Longman