Re: [PATCH V2 0/8] cpusets: Isolate CPUs via sysfs using cpusets

[Mike Galbraith <umgwanakikbuti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Mon, 2014-04-07 at 09:41 +0530, Viresh Kumar wrote: 
> Hi Mike,
> 
> On 6 April 2014 14:00, Mike Galbraith <umgwanakikbuti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > I wonder if adding a quiesce switch is really necessary.
> >
> > Seems to me that if you don't have load balancing turned off, you can't
> > be very concerned about perturbation, so this should be tied into the
> > load balancing on/off switch as an extension to isolating cores from the
> > #1 perturbation source, the scheduler.
> 
> Its more about not doing any background activities on these CPU which can
> be avoided. So, even if a add_timer() is issued from these isolated CPUs, it
> should goto the set chosen for doing background activity, unless add_timer_on()
> has been issued, in which case user wants that code to execute on the
> isolated core.
> 
> Probably, yes, people would be disabling load_balancing between these
> cpusets to avoid migration of tasks to isolated core as well.. Atleast we
> are using it :)

Yes, that's the whole point I'm trying to make.  If you do not have
cores isolated, there's no point to quiesce, as timers and whatnot are
the least of your worries.  Conversely, why would you bother isolating
cores if you didn't want a nice quiet environment.  Seems to me full
isolation ala killing sched domains implies that your goal is bare
metal.. or as close as you can get to that anyway.

> > I also didn't notice a check for is_cpu_exclusive() at a glance, which
> > would be a bug, but one that would go away if this additional isolation
> > were coupled to the existing isolation switch.
> 
> Yeah, there is no check for that. But I didn't got your point completely.
> Why do I need to check for exclusivity on the isolated CPUs? So, that
> same CPU isn't isolated as well as non-isolated on two separate sets?

Yes, both on and off is kinda hard to do per cpu :)

-Mike