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!
WARNING: multiple messages have this Message-ID (diff)
From: Frederic Weisbecker <frederic-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Marcelo Tosatti <mtosatti-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, Juri Lelli <juri.lelli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Alex Belits <abelits-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>, Nitesh Lal <nilal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>, Nicolas Saenz <nsaenzju-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Christoph Lameter <cl-LoxgEY9JZOazQB+pC5nmwQ@public.gmane.org>, Zefan Li <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.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-ZB2g03Rrq1XR7s880joybQ@public.gmane.org> 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!
next prev parent reply other threads:[~2021-07-19 13:26 UTC|newest] Thread overview: 34+ 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 ` 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 ` 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 ` Frederic Weisbecker 2021-07-14 13:54 ` [RFC PATCH 5/6] sched/isolation: Make HK_FLAG_DOMAIN mutable Frederic Weisbecker 2021-07-14 13:54 ` 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 13:54 ` Frederic Weisbecker 2021-07-14 16:31 ` Marcelo Tosatti 2021-07-19 13:26 ` Frederic Weisbecker [this message] 2021-07-19 13:26 ` Frederic Weisbecker 2021-07-19 15:41 ` Marcelo Tosatti 2021-07-19 15:41 ` Marcelo Tosatti 2021-07-14 16:52 ` Peter Zijlstra 2021-07-14 16:52 ` Peter Zijlstra 2021-07-14 23:13 ` Frederic Weisbecker 2021-07-14 23:13 ` Frederic Weisbecker 2021-07-14 23:44 ` Valentin Schneider 2021-07-14 23:44 ` Valentin Schneider 2021-07-15 0:07 ` Frederic Weisbecker 2021-07-15 0:07 ` Frederic Weisbecker 2021-07-15 9:04 ` Peter Zijlstra 2021-07-15 9:04 ` Peter Zijlstra 2021-07-19 13:17 ` Frederic Weisbecker 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-16 18:02 ` Waiman Long 2021-07-19 13:57 ` Frederic Weisbecker 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 \ /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: linkBe 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.