LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Alex Belits <abelits@marvell.com>, Nitesh Lal <nilal@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Nicolas Saenz <nsaenzju@redhat.com>,
	Christoph Lameter <cl@gentwo.de>,
	Zefan Li <lizefan.x@bytedance.com>,
	cgroups@vger.kernel.org
Subject: Re: [RFC PATCH 6/6] cpuset: Add cpuset.isolation_mask file
Date: Mon, 19 Jul 2021 15:26:49 +0200	[thread overview]
Message-ID: <20210719132649.GB116346@lothringen> (raw)
In-Reply-To: <20210714163157.GA140679@fuller.cnet>

On Wed, Jul 14, 2021 at 01:31:57PM -0300, Marcelo Tosatti wrote:
> On Wed, Jul 14, 2021 at 03:54:20PM +0200, Frederic Weisbecker wrote:
> > Add a new cpuset.isolation_mask file in order to be able to modify the
> > housekeeping cpumask for each individual isolation feature on runtime.
> > In the future this will include nohz_full, unbound timers,
> > unbound workqueues, unbound kthreads, managed irqs, etc...
> > 
> > Start with supporting domain exclusion and CPUs passed through
> > "isolcpus=".
> 
> It is possible to just add return -ENOTSUPPORTED for the features 
> whose support is not present?

Maybe, although that looks like a specialized error for corner cases.

> > 
> > CHECKME: Should we have individual cpuset.isolation.$feature files for
> >          each isolation feature instead of a single mask file?
> 
> Yes, guess that is useful, for example due to the -ENOTSUPPORTED
> comment above.
> 
> 
> Guarantees on updates
> =====================
> 
> Perhaps start with a document with:
> 
> On return to the write to the cpumask file, what are the guarantees?
> 
> For example, for kthread it is that any kernel threads from that point
> on should start with the new mask. Therefore userspace should 
> respect the order:
> 
> 1) Change kthread mask.
> 2) Move threads.
> 

Yep.

> Updates to interface
> ====================
> 
> Also, thinking about updates to the interface (which today are one
> cpumask per isolation feature) might be useful. What can happen:
> 
> 1) New isolation feature is added, feature name added to the interface.
> 
> Userspace must support new filename. If not there, then thats an 
> old kernel without support for it.
> 
> 2) If an isolation feature is removed, a file will be gone. What should
> be the behaviour there? Remove the file? (userspace should probably 
> ignore the failure in that case?) (then features names should not be
> reused, as that can confuse #1 above).

Heh, yeah that's complicated. I guess we should use one flag per file as that
fits well within the current cpuset design. But we must carefully choose the new
files to make sure they have the least chances to be useless in the long term.

> Or maybe have a versioned scheme?

I suspect we should avoid that at all costs :-)

Thanks!

  reply	other threads:[~2021-07-19 13:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14 13:54 [RFC PATCH 0/6] cpuset: Allow to modify isolcpus through cpuset Frederic Weisbecker
2021-07-14 13:54 ` [RFC PATCH 1/6] pci: Decouple HK_FLAG_WQ and HK_FLAG_DOMAIN cpumask fetch Frederic Weisbecker
2021-07-14 13:54 ` [RFC PATCH 2/6] workqueue: " Frederic Weisbecker
2021-07-14 13:54 ` [RFC PATCH 3/6] net: " Frederic Weisbecker
2021-07-14 13:54 ` [RFC PATCH 4/6] sched/isolation: Split domain housekeeping mask from the rest Frederic Weisbecker
2021-07-14 13:54 ` [RFC PATCH 5/6] sched/isolation: Make HK_FLAG_DOMAIN mutable Frederic Weisbecker
2021-07-21 14:28   ` Vincent Donnefort
2021-07-14 13:54 ` [RFC PATCH 6/6] cpuset: Add cpuset.isolation_mask file Frederic Weisbecker
2021-07-14 16:31   ` Marcelo Tosatti
2021-07-19 13:26     ` Frederic Weisbecker [this message]
2021-07-19 15:41       ` Marcelo Tosatti
2021-07-14 16:52   ` Peter Zijlstra
2021-07-14 23:13     ` Frederic Weisbecker
2021-07-14 23:44       ` Valentin Schneider
2021-07-15  0:07         ` Frederic Weisbecker
2021-07-15  9:04       ` Peter Zijlstra
2021-07-19 13:17         ` Frederic Weisbecker
2021-07-16 18:02 ` [RFC PATCH 0/6] cpuset: Allow to modify isolcpus through cpuset Waiman Long
2021-07-19 13:57   ` Frederic Weisbecker

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=20210719132649.GB116346@lothringen \
    --to=frederic@kernel.org \
    --cc=abelits@marvell.com \
    --cc=cgroups@vger.kernel.org \
    --cc=cl@gentwo.de \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=mtosatti@redhat.com \
    --cc=nilal@redhat.com \
    --cc=nsaenzju@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --subject='Re: [RFC PATCH 6/6] cpuset: Add cpuset.isolation_mask file' \
    /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

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).