Messages in this thread | | | Date | Sun, 03 Oct 2004 16:53:40 -0700 | From | "Martin J. Bligh" <> | Subject | Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement |
| |
> Martin wrote: >> Matt had proposed having a separate sched_domain tree for each cpuset, which >> made a lot of sense, but seemed harder to do in practice because "exclusive" >> in cpusets doesn't really mean exclusive at all. > > See my comments on this from yesterday on this thread. > > I suspect we don't want a distinct sched_domain for each cpuset, but > rather a sched_domain for each of several entire subtrees of the cpuset > hierarchy, such that every CPU is in exactly one such sched domain, even > though it be in several cpusets in that sched_domain.
Mmmm. The fundamental problem I think we ran across (just whilst pondering, not in code) was that some things (eg ... init) are bound to ALL cpus (or no cpus, depending how you word it); i.e. they're created before the cpusets are, and are a member of the grand-top-level-uber-master-thingummy.
How do you service such processes? That's what I meant by the exclusive domains aren't really exclusive.
Perhaps Matt can recall the problems better. I really liked his idea, aside from the small problem that it didn't seem to work ;-)
> So we have eight cpusets, non-overlapping and covering the entire > system, each with its own sched_domain.
But that's the problem ... I think there are *always* cpusets that overlap. Which is sad (fixable?) because it breaks lots of intelligent things we could do.
> purposes. I am afraid I've forgotten too much of my math from long long > ago to state this with exactly the right terms.
That's OK, so have most of the rest of us, so even if you could remember, it wouldn't help much ;-)
M.
- 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/
| |