linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Jonathan Corbet <corbet@lwn.net>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Neeraj Upadhyay <quic_neeraju@quicinc.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Shuah Khan <shuah@kernel.org>,
	cgroups@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
	linux-kselftest@vger.kernel.org, Mrunal Patel <mpatel@redhat.com>,
	Ryan Phillips <rphillips@redhat.com>,
	Brent Rowsell <browsell@redhat.com>,
	Peter Hunt <pehunt@redhat.com>,
	Cestmir Kalina <ckalina@redhat.com>,
	Nicolas Saenz Julienne <nsaenz@kernel.org>,
	Alex Gladkov <agladkov@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Phil Auld <pauld@redhat.com>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Daniel Bristot de Oliveira <bristot@kernel.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Costa Shulyupin <cshulyup@redhat.com>
Subject: Re: [RFC PATCH 0/8] cgroup/cpuset: Support RCU_NOCB on isolated partitions
Date: Tue, 6 Feb 2024 13:56:23 +0100	[thread overview]
Message-ID: <ZcIsd6fjgmsb2dxr@localhost.localdomain> (raw)
In-Reply-To: <5ee5bf79-6cdc-4d1b-a19f-f0d5165a5f16@redhat.com>

Le Wed, Jan 17, 2024 at 12:15:07PM -0500, Waiman Long a écrit :
> 
> On 1/17/24 12:07, Tejun Heo wrote:
> > Hello,
> > 
> > On Wed, Jan 17, 2024 at 11:35:03AM -0500, Waiman Long wrote:
> > > The first 2 patches are adopted from Federic with minor twists to fix
> > > merge conflicts and compilation issue. The rests are for implementing
> > > the new cpuset.cpus.isolation_full interface which is essentially a flag
> > > to globally enable or disable full CPU isolation on isolated partitions.
> > I think the interface is a bit premature. The cpuset partition feature is
> > already pretty restrictive and makes it really clear that it's to isolate
> > the CPUs. I think it'd be better to just enable all the isolation features
> > by default. If there are valid use cases which can't be served without
> > disabling some isolation features, we can worry about adding the interface
> > at that point.
> 
> My current thought is to make isolated partitions act like isolcpus=domain,
> additional CPU isolation capabilities are optional and can be turned on
> using isolation_full. However, I am fine with making all these turned on by
> default if it is the consensus.

Right it was the consensus last time I tried. Along with the fact that mutating
this isolation_full set has to be done on offline CPUs to simplify the whole
picture.

So lemme try to summarize what needs to be done:

1) An all-isolation feature file (that is, all the HK_TYPE_* things) on/off for
  now. And if it ever proves needed, provide a way later for more finegrained
  tuning.

2) This file must only apply to offline CPUs because it avoids migrations and
  stuff.

3) I need to make RCU NOCB tunable only on offline CPUs, which isn't that much
   changes.

4) HK_TYPE_TIMER:
   * Wrt. timers in general, not much needs to be done, the CPUs are
     offline. But:
   * arch/x86/kvm/x86.c does something weird
   * drivers/char/random.c might need some care
   * watchdog needs to be (de-)activated
   
5) HK_TYPE_DOMAIN:
   * This one I fear is not mutable, this is isolcpus...

6) HK_TYPE_MANAGED_IRQ:
   * I prefer not to think about it :-)

7) HK_TYPE_TICK:
   * Maybe some tiny ticks internals to revisit, I'll check that.
   * There is a remote tick to take into consideration, but again the
     CPUs are offline so it shouldn't be too complicated.

8) HK_TYPE_WQ:
   * Fortunately we already have all the mutable interface in place.
     But we must make it live nicely with the sysfs workqueue affinity
     files.

9) HK_FLAG_SCHED:
   * Oops, this one is ignored by nohz_full/isolcpus, isn't it?
   Should be removed?

10) HK_TYPE_RCU:
    * That's point 3) and also some kthreads to affine, which leads us
     to the following in HK_TYPE_KTHREAD:

11) HK_FLAG_KTHREAD:
    * I'm guessing it's fine as long as isolation_full is also an
      isolated partition. Then unbound kthreads shouldn't run there.

12) HK_TYPE_MISC:
    * Should be fine as ILB isn't running on offline CPUs.

Thanks.

  reply	other threads:[~2024-02-06 12:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-17 16:35 [RFC PATCH 0/8] cgroup/cpuset: Support RCU_NOCB on isolated partitions Waiman Long
2024-01-17 16:35 ` [RFC PATCH 1/8] rcu/nocb: Pass a cpumask instead of a single CPU to offload/deoffload Waiman Long
2024-01-17 16:35 ` [RFC PATCH 2/8] rcu/nocb: Prepare to change nocb cpumask from CPU-hotplug protected cpuset caller Waiman Long
2024-01-17 16:35 ` [RFC PATCH 3/8] rcu/no_cb: Add rcu_nocb_enabled() to expose the rcu_nocb state Waiman Long
2024-01-17 16:35 ` [RFC PATCH 4/8] cgroup/cpuset: Better tracking of addition/deletion of isolated CPUs Waiman Long
2024-01-17 16:35 ` [RFC PATCH 5/8] cgroup/cpuset: Add cpuset.cpus.isolation_full Waiman Long
2024-01-17 16:35 ` [RFC PATCH 6/8] cgroup/cpuset: Enable dynamic rcu_nocb mode on isolated CPUs Waiman Long
2024-01-17 16:35 ` [RFC PATCH 7/8] cgroup/cpuset: Document the new cpuset.cpus.isolation_full control file Waiman Long
2024-01-17 16:35 ` [RFC PATCH 8/8] cgroup/cpuset: Update test_cpuset_prs.sh to handle cpuset.cpus.isolation_full Waiman Long
2024-01-17 17:07 ` [RFC PATCH 0/8] cgroup/cpuset: Support RCU_NOCB on isolated partitions Tejun Heo
2024-01-17 17:15   ` Waiman Long
2024-02-06 12:56     ` Frederic Weisbecker [this message]
2024-02-06 19:15       ` Marcelo Tosatti
2024-02-07 14:47         ` Frederic Weisbecker
2024-02-07 14:59           ` Marcelo Tosatti
2024-02-10  4:19       ` Waiman Long
2024-01-19 10:24 ` Paul E. McKenney
2024-02-11  1:46   ` Waiman Long
2024-01-22 15:07 ` Michal Koutný
2024-01-23  5:50   ` Waiman Long

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=ZcIsd6fjgmsb2dxr@localhost.localdomain \
    --to=frederic@kernel.org \
    --cc=agladkov@redhat.com \
    --cc=boqun.feng@gmail.com \
    --cc=bristot@kernel.org \
    --cc=browsell@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=ckalina@redhat.com \
    --cc=corbet@lwn.net \
    --cc=cshulyup@redhat.com \
    --cc=dave@stgolabs.net \
    --cc=hannes@cmpxchg.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=longman@redhat.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mpatel@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=nsaenz@kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=pauld@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=pehunt@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qiang.zhang1211@gmail.com \
    --cc=quic_neeraju@quicinc.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=rphillips@redhat.com \
    --cc=shuah@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).