Messages in this thread | | | Date | Mon, 18 Apr 2005 23:59:02 -0700 | From | Paul Jackson <> | Subject | Re: [RFC PATCH] Dynamic sched domains aka Isolated cpusets |
| |
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.
> 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"
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.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |