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!
