[Lse-tech] Re: [RFC PATCH] Dynamic sched domains aka Isolated cpusets

[Nick P. <nic...@ya...>]

On Mon, 2005-04-18 at 23:59 -0700, Paul Jackson wrote:
> Nick wrote:
> >  Basically you just have to know that it has the
> > capability to partition the system in an arbitrary disjoint set
> > of sets of cpus.
> > 
> > If you can make use of that, then we're in business ;)
> 
> You read fast ;)
> 
> So you do _not_ want to consider nested sched domains, just disjoint
> ones.  Good.
> 

You don't either? Good. :)

> 
> > From what I gather, this partitioning does not exactly fit
> > the cpusets architecture. Because with cpusets you are specifying
> > on what cpus can a set of tasks run, not dividing the whole system.
> 
> My evil scheme, and Dinakar's as well, is to provide a way for the user
> to designate _some_ of their cpusets as also defining the partition that
> controls which cpus are in each sched domain, and so dividing the
> system.
> 
>   "partition" == "an arbitrary disjoint set of sets of cpus"
> 

That would make sense. I'm not familiar with the workings of cpusets,
but that would require every task to be assigned to one of these
sets (or a subset within it), yes?

> This fits naturally with the way people use cpusets anyway.  They divide
> up the system along boundaries that are natural topologically and that
> provide a good fit for their jobs, and hope that the kernel will adapt
> to such localized placement.  They then throw a few more nested (smaller)
> cpusets at the problem, to deal with various special needs.  If we can
> provide them with a means to tell us which of their cpusets define the
> natural partitioning of their system, for the job mix and hardware
> topology they have, then all is well.
> 

Sounds like a good fit then. I'll touch up the sched-domains side of
the equation when I get some time hopefully this week or next.

-- 
SUSE Labs, Novell Inc.