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

[Dinakar Guniguntala <dino@in.ibm.com>]

On Mon, Oct 16, 2006 at 04:03:51PM -0700, Paul Jackson wrote:
> From: Paul Jackson <pj@sgi.com>
> 
> I should get agreement from the other folks who care about the
> interaction of cpusets and sched domains before submitting this
> to Andrew for staging in *-mm.
> 
> In particular, I remain unsure of myself around the sched domain
> code, and could use some feedback from someone with more of a
> clue on whether I broke something here.
> 
> =======
> 
> I have long regretted hanging the ability to use cpusets to
> define dynamic scheduler domains off the 'cpu_exclusive' flag
> of cpusets.

I seem to recollect having this very discussion before and
we had agreed that backing up a cpu_exclusive cpuset with a 
sched domain was an optimization rather than overloading the 
cpu_exclusive flag and I dont think it has changed since then.

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


> 
> In the interests of maintaining compatibility with the
> existing interface, we should not remove this overloading of
> the cpu_exclusive flag.  But we can add a new flag to define
> sched domains, and a second flag to activate this first flag.

[snip]

IMO this change is counter intuitive and pointless

	-Dinakar

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