Messages in this thread | | | Subject | Re: [RFC PATCH] Dynamic sched domains aka Isolated cpusets | From | Nick Piggin <> | Date | Tue, 19 Apr 2005 17:09:43 +1000 |
| |
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.
- 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/
| |