On Mon, Aug 28, 2017 at 03:23:06PM +0200, Frederic Weisbecker wrote: > On Mon, Aug 28, 2017 at 12:09:57PM +0200, Peter Zijlstra wrote: > > On Wed, Aug 23, 2017 at 03:51:11AM +0200, Frederic Weisbecker wrote: > > > We want to centralize the isolation features on the housekeeping > > > subsystem and scheduler isolation is a significant part of it. > > > > > > While at it, this is a proposition for a reimplementation of isolcpus= > > > that doesn't involve scheduler domain isolation. Therefore this > > > brings a behaviour change: all user tasks inherit init/1 affinity which > > > avoid the isolcpus= range. But if a task later overrides its affinity > > > which turns out to intersect an isolated CPU, load balancing may occur > > > on it. > > > > > > OTOH such a reimplementation that doesn't shortcut scheduler internals > > > makes a better candidate for an interface extension to cpuset. > > > > Not sure we can do this. It'll break users that rely on the no > > scheduling thing, that's a well documented part of isolcpus. > > That was my worry :-s That NULL domain was probably a design mistake and > I fear we now have to maintain it.
I'm fairly sure that was very intentional. If you want to isolate stuff you don't want load-balancing. You get the same NULL domain with cpusets if you disable balancing for a set of CPUs. Now, I completely hate the isolcpus feature and wish is a speedy death, but replacing it with something sensible is difficult because cgroups :-(
