Re: [RFC] Cpuset: explicit dynamic sched domain control flags

[Paul Jackson <pj@sgi.com>]

> > 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/