Messages in this thread | | | Date | Wed, 18 Oct 2006 23:00:55 -0700 | From | Paul Jackson <> | Subject | Re: [RFC] Cpuset: explicit dynamic sched domain control flags |
| |
> > It sort of made sense, in that one wants to avoid overlapping > > sched domains to some extent. However it conflicts with other > > uses and meanings of the cpu_exclusive flag. In particular, > > a job manager cannot have an inactive job in a cpuset that > > overlaps an active job, and mark the active job as defining a > > sched domain. > > Sorry I dont understand this at all. Particularly marking > an active job as a sched domain (I am yet to read all of the > mails in this thread, so please bear with me if you have > answered this elsewhere) > > The only additional thing that happens once a cpuset has a > sched domain associated with it would that the rebalance code > running on cpus not part of this cpuset would now not pull > tasks from the exclusive cpuset. How is that bad in any way ??
The reason that an active job could not be made a sched domain when its cpus overlapped an inactive job is that the cpu_exclusive rules forbid any cpu_exclusive cpuset overlapping any sibling cpuset.
However ... this is basically just confirming for me my suspicion that the Cpuset folks don't grok Sched Domains, and vice versa.
Time to remove this linkage between them that no one really understands from both sides, and that apparently is broken and not safely usable.
Once I catch up on todays email, I will send out a patch to remove this code linking cpuset cpu_exclusive to sched domains, replacing it with a much simpler mechanism allowing for runtime control of the cpu_isolated_map
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 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/
| |