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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0F62C433F5 for ; Fri, 27 May 2022 12:58:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351449AbiE0M64 (ORCPT ); Fri, 27 May 2022 08:58:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349209AbiE0M6y (ORCPT ); Fri, 27 May 2022 08:58:54 -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 1A3AF3527A for ; Fri, 27 May 2022 05:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653656332; 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: in-reply-to:in-reply-to:references:references; bh=zdUWMIkaVQo5/ztJhdqUq/oyKx8W5hvof7Mbhxo94Xo=; b=J0r4sKAOGQQkiuIn/EvhbgFnpXw0If+p0G1zAmYaF2yWSqwl6ffLqyb8yCfHnuhwWi5DgY z3su95pwvfWrGXoMNK6TTisOgUYXjE8cxGJVwX8lxqPb0AcIp7uALUqiM8+BpnffDo4Fss VtTmMWv7QAFL8atD9Yz7vRCFi61pPUA= 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-328-KF64FyXdNgWzknneb9PXnQ-1; Fri, 27 May 2022 08:58:48 -0400 X-MC-Unique: KF64FyXdNgWzknneb9PXnQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5CDB880B71A; Fri, 27 May 2022 12:58:48 +0000 (UTC) Received: from pauld.bos.csb (dhcp-17-51.bos.redhat.com [10.18.17.51]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 058C340EC002; Fri, 27 May 2022 12:58:46 +0000 (UTC) Date: Fri, 27 May 2022 08:58:45 -0400 From: Phil Auld To: Tejun Heo Cc: Juri Lelli , Waiman Long , Frederic Weisbecker , LKML , Peter Zijlstra , "Paul E . McKenney" , Paul Gortmaker , Johannes Weiner , Marcelo Tosatti , Zefan Li , Daniel Bristot de Oliveira , Nicolas Saenz Julienne , rcu@vger.kernel.org Subject: Re: [RFC PATCH 4/4] cpuset: Support RCU-NOCB toggle on v2 root partitions Message-ID: <20220527125844.GA26124@pauld.bos.csb> References: <20220525221055.1152307-1-frederic@kernel.org> <20220525221055.1152307-5-frederic@kernel.org> <20220526225141.GA1214445@lothringen> <9e44bb00-955a-dbc6-a863-be649e0c701f@redhat.com> <20220527083018.n43nc73vuuzm5ixo@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, May 26, 2022 at 10:45:00PM -1000 Tejun Heo wrote: > Hello, > > On Fri, May 27, 2022 at 10:30:18AM +0200, Juri Lelli wrote: > > FWIW, I was under the impression that this would nicely fit along the > > side of other feaures towards implenting dynamic isolation of CPUs (say > > https://lore.kernel.org/lkml/20220510153413.400020-1-longman@redhat.com/ > > for example). Wouldn't be awkward to have to poke different places to > > achieve isolation at runtime? > > So, it were just being part of the isolated domain thing, it would make > sense, but as a separate flag which isn't hierarchical, it's weird to put it > there. The way I see it is more that the "isolated domain thing" is one part of this whole dynamic isolation thing and is just one flag among many (most still on the drawing board, but planned). It may be that Waiman's "isolated" should be renamed "no_load_balance" or something. Part of this is making cpu isolation more granular. > > > Also, I wonder if a proc/sys interface might be problematic for certain > > middleware that is substantially based on using cgroups. I'll try to ask > > around. :) > > There is a downside to making a feature a part of cpuset in that it makes > cgroup usage mandatory. This is fine for something which benefits from > hierarchical organization but it is weird to require building cgroup > hierarchy for straight-forward system-wide features. > That ship may have sailed when SD_LOAD_BALANCE was removed, which is part of what Waiman's feature addresses. That is, now in order to get control over the system-wide feature of which CPUs get scheduler load balanced you need to use cpusets. My 3 cents anyway (inflation ;) Cheers, Phil > Thanks. > > -- > tejun > --