All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <frederic@kernel.org>
Cc: Juri Lelli <juri.lelli@redhat.com>, Tejun Heo <tj@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Phil Auld <pauld@redhat.com>, Zefan Li <lizefan.x@bytedance.com>,
	Daniel Bristot de Oliveira <bristot@kernel.org>,
	Nicolas Saenz Julienne <nsaenz@kernel.org>,
	rcu@vger.kernel.org
Subject: Re: [RFC PATCH 4/4] cpuset: Support RCU-NOCB toggle on v2 root partitions
Date: Tue, 31 May 2022 10:21:03 -0400	[thread overview]
Message-ID: <6936d198-7ae4-e022-20d5-e60c17f119e8@redhat.com> (raw)
In-Reply-To: <YpTDq6Z/+hp+CHwf@worktop.programming.kicks-ass.net>

On 5/30/22 09:16, Peter Zijlstra wrote:
> On Mon, May 30, 2022 at 12:56:50PM +0200, Frederic Weisbecker wrote:
>
>>> This is ABI, you can't walk back on it. I would suggest starting with an
>>> 'all feature' isolation. Only if there's real demand for something more
>>> fine-grained add that on top. Simple first etc.
>> That's actually my worry. If we start with an all in one ABI, how do we later
>> mix that up with more finegrained features? Like what will be the behaviour of:
>>
>> cpuset.isolation.rcu_nocb = 0
>> cpuset.isolation.all = 1
> Well clearly that doesn't make sense. I was more thinking along the
> lines of cgroup.subtree_control, where instead all features are enabled
> by default.
>
> But only if there's a real usecase, otherwise there's no point in
> providing such knobs.

I am actually thinking about extending the cpuset partition interface 
for isolation. Right now, I have an outstanding patch [1] to add an 
"isolated" state to partition which disable load balancing somewhat 
similar to isolcpus command line option. In the future, we can add 
attribute to the isolation state like "isolated:full" to similar to 
nohz_full currently. If the needs arise, we can even  extend the 
attribute to allow list like "isolated:rcu_nocbs". I don't think it is 
good idea to keep on adding new cpuset control files extensively. I 
would prefer extending the existing ones.

[1] https://lore.kernel.org/lkml/20220510153413.400020-1-longman@redhat.com/

Cheers,
Longman


  parent reply	other threads:[~2022-05-31 14:21 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-25 22:10 [PATCH 0/4] rcu/cpuset: Control RCU_NOCB offloading through cpusets Frederic Weisbecker
2022-05-25 22:10 ` [PATCH 1/4] rcu/nocb: Pass a cpumask instead of a single CPU to offload/deoffload Frederic Weisbecker
2022-05-25 22:19   ` Frederic Weisbecker
2022-05-25 22:42     ` Paul E. McKenney
2022-05-25 22:10 ` [PATCH 2/4] rcu/nocb: Prepare to change nocb cpumask from CPU-hotplug protected cpuset caller Frederic Weisbecker
2022-05-25 22:10 ` [PATCH 3/4] sched/isolation: Infrastructure to support rcu nocb cpumask changes Frederic Weisbecker
2022-08-19  7:12   ` Tobias Huschle
2022-05-25 22:10 ` [RFC PATCH 4/4] cpuset: Support RCU-NOCB toggle on v2 root partitions Frederic Weisbecker
2022-05-26 18:21   ` Tejun Heo
2022-05-26 22:51     ` Frederic Weisbecker
2022-05-26 23:02       ` Tejun Heo
2022-05-27  0:28         ` Waiman Long
2022-05-27  0:37           ` Tejun Heo
2022-05-27  8:30             ` Juri Lelli
2022-05-27  8:45               ` Tejun Heo
2022-05-27 12:58                 ` Phil Auld
2022-05-28 14:24               ` Peter Zijlstra
2022-05-30  0:40                 ` Frederic Weisbecker
2022-05-30  8:11                   ` Peter Zijlstra
2022-05-30 10:56                     ` Frederic Weisbecker
2022-05-30 13:16                       ` Peter Zijlstra
2022-05-30 14:13                         ` Juri Lelli
2022-05-30 21:35                         ` Frederic Weisbecker
2022-05-31  0:57                           ` Tejun Heo
2022-05-31 14:21                         ` Waiman Long [this message]
2022-05-30 14:29                   ` nicolas saenz julienne
2022-05-30 14:49                     ` Paul E. McKenney
2022-05-30 22:36                       ` Alison Chaiken

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6936d198-7ae4-e022-20d5-e60c17f119e8@redhat.com \
    --to=longman@redhat.com \
    --cc=bristot@kernel.org \
    --cc=frederic@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=mtosatti@redhat.com \
    --cc=nsaenz@kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=pauld@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rcu@vger.kernel.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.