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:

quoted

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.

quoted

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!