Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement

[Paul Jackson]

Erich wrote:
> > Can CKRM (as it is now) fulfil the requirements?
> ...
> [CKRM] doesn't care about the structure of the machine

Hubertus wrote:
> You forget that CKRM does NOT violate ... cpus_allowed ...
> ...
> In order to allow CKRM scheduling within a cpuset ...

I sense a disconnect here.

Seems to me Erich was asking if CKRM could be used _instead_ of cpusets,
and observes that, for now at least, CKRM lacks something.

Seems to me Hubertus is, _in_ _part_, responding to the question of
whether CKRM can be used _within_ cpusets, and claims to be taking a
position opposite to Erich's, protesting that indeed CKRM can be used
within cpusets - CKRM doesn't violate cpus_allowed constraints.

Hubertus - I didn't realize that Erich considered that question, not did
I realize he took that position.

Unfortunately, the plot thickens.  Hubertus goes on it seems to consider
other questions, and I start to lose the thread of his thought.  Such
questions as:

 - can RCFS/controllers set cpus_allowed as do cpusets?
	[ beware that there's more to cpusets than setting cpus_allowed ]
 - can cpusets replace shared based scheduling?
 - can share based scheduling replace cpusets?
 - can CKRM scheduling be allowed within cpusets?
 - are sibling cpusets exclusive?
	[ yes - if the exclusive property is set on them ]
 - can we enforce that a certain task class is limited to a cpuset subtree?

By now I'm thoroughly confused.  Fortunately, Hubertus concludes:

  - If we agree or disagree then we can work on a proposal for this.

Well, since I'm pretty sure from my Logic 101 class that we agree or
disagree, this is good news.  I'm glad to hear we can work on a proposal
on this [ what was 'this' again ...? ;) ]

One thing I am sure of ... either one of Hubertus or myself needs another
cup of coffee, or both Hubertus and I need to have a beer together.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@xxxxxxx> 1.650.933.1373
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/