Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2369158ioo; Sat, 28 May 2022 11:30:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKd4+FIv3LkLoiU6iBR2IZbpoCDUFBF+SIDO50zArLzCb9WJ1LuYpvPIoPWgbDLvCkZ/DQ X-Received: by 2002:a05:6a00:3495:b0:518:5199:c58a with SMTP id cp21-20020a056a00349500b005185199c58amr44384378pfb.58.1653762639794; Sat, 28 May 2022 11:30:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653762639; cv=none; d=google.com; s=arc-20160816; b=F8U3M8/51Wa4/QmkuX1Yw+gr8DM39oWobIW3q4FjlyWMTgFsL3Z5Kc2dF4Jv343mO8 cgnE4pn64E0MUaQ8v8vNvm0NyKBGdidQSdMfwzn8e9BJVUgTUFkS4wj5b56+ZBfA21jw iY7zL614mqORhKK4EGuR6WTZc19sK+BK4p3rXHqBQznYaPgw1YAY0AsjdMWV8bUtVWYb 7bVHH7sdWoxDoz59+YF12IvqeoMrUTPoKh3/1uEF+DRlMLKhJIBFMGu8cRp6i223VKzB oF7xtnMeRjm81pY5X60nsmV4Z1JOzw0fuEE8nD9YYBv7rdCiw3WQjk77oLklU0FlTk0O 0sLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=Pg40jcleVGao/8yHsoU02qSsKOhI2WnVp+h1zYAfdd4=; b=ZL37T+CQoph7JxSFbwj4gF3wt51ChsbZf0uPMamrDKK0tyn1UvoG2oL6LgmJaF4b8p +RZMgbU1UzyIohz/kGn5RdFvWUljQ0ZvAtNGp3TXeDP9Nur3E5MtLuksvKDGaK3+ZJ1e rmSdrnlnW1pKMalczo3aQuUhMyFEC7hH2pJe+m8nd7FCCXD2o5TRkGxZ2EXCJ07BDIN4 OImNfkTpdgYYYzEfSYbAv21qiA5n0IzTAy2QHmzYeiSTgpBuRfNYm++Fma1aSdP9fDra vX9pjH6ImFgG3/h7cCJdk7C0yX4okYmiCkl4egYkyd5RF7GMH6xqzDOgvHIZlI6unL5G rm2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TsuP1yIH; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id h6-20020a170902f70600b0015a39e94e61si9159869plo.420.2022.05.28.11.30.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 May 2022 11:30:39 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TsuP1yIH; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AF07163B9; Sat, 28 May 2022 11:28:09 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231211AbiE0A2y (ORCPT + 99 others); Thu, 26 May 2022 20:28:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231130AbiE0A2v (ORCPT ); Thu, 26 May 2022 20:28:51 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EC0FB79823 for ; Thu, 26 May 2022 17:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653611330; 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=Pg40jcleVGao/8yHsoU02qSsKOhI2WnVp+h1zYAfdd4=; b=TsuP1yIH1U4QdlKqS7T7f2B8pb4f5H+dHpk+OwI0CSzq2G1U+GhyzCnEbm9K0udycgvF/B WLDY+Kev3zL9V/ran2FqNSygV6LL8IpodhJfr745Sd1UOOO1Cfms4fRDchkwvhELIYLPx3 J5I60tMQAVsZNbqyUhpbnhOgoNbgzeM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-96-8aORyOwBM3mouTFMHQlP8Q-1; Thu, 26 May 2022 20:28:45 -0400 X-MC-Unique: 8aORyOwBM3mouTFMHQlP8Q-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2CA3185A5BC; Fri, 27 May 2022 00:28:45 +0000 (UTC) Received: from [10.22.8.143] (unknown [10.22.8.143]) by smtp.corp.redhat.com (Postfix) with ESMTP id 33965492C3B; Fri, 27 May 2022 00:28:44 +0000 (UTC) Message-ID: <9e44bb00-955a-dbc6-a863-be649e0c701f@redhat.com> Date: Thu, 26 May 2022 20:28:43 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [RFC PATCH 4/4] cpuset: Support RCU-NOCB toggle on v2 root partitions Content-Language: en-US To: Tejun Heo , Frederic Weisbecker Cc: LKML , Peter Zijlstra , "Paul E . McKenney" , Paul Gortmaker , Johannes Weiner , Marcelo Tosatti , Phil Auld , Zefan Li , Daniel Bristot de Oliveira , Nicolas Saenz Julienne , rcu@vger.kernel.org References: <20220525221055.1152307-1-frederic@kernel.org> <20220525221055.1152307-5-frederic@kernel.org> <20220526225141.GA1214445@lothringen> From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/26/22 19:02, Tejun Heo wrote: > On Fri, May 27, 2022 at 12:51:41AM +0200, Frederic Weisbecker wrote: >>> Does it even make sense to make this hierarchical? What's wrong with a >>> cpumask under sys/ or proc/? >> I'm usually told that cpusets is the current place where CPU attributes are >> supposed to go. I personally don't mind much /sys either even though cpusets >> looks like a more flexible way to partition CPUs with properties and tasks >> placement altogether... > Yeah, I mean, if it's hierarchical, it's the right place but I have a hard > time seeing anything hierarchical with this one. Somebody just has to know > which cpus are up for rcu processing and which aren't. Waiman, what do you > think? I am thinking along the line that it will not be hierarchical. However, cpuset can be useful if we want to have multiple isolated partitions underneath the top cpuset with different isolation attributes, but no more sub-isolated partition with sub-attributes underneath them. IOW, we can only set them at the first level under top_cpuset. Will that be useful? Cheers, Longman