Re: [Lse-tech] Re: CPUSET Proposal

From: William Lee Irwin III <wli_at_holomorphy.com>
Date: 2003-09-25 16:23:51
At some point in the past, I wrote:
>> This sounds like it has progressively more commonality with CKRM; the
>> notion is of a workclass, not of a purely cpu-oriented notion.

On Wed, Sep 24, 2003 at 11:09:58PM -0700, Paul Jackson wrote:
> I _knew_ I shouldn't have thrown in that paragraph that began "There are
> also some resource management capabilities, ...".
> There are two aspects to CKRM - a common classification of service levels,
> and hooks in each scheduler of resources to respect those levels.
> These cpusets, either as proposed, or possible fancier forms that also
> manage memory, do not replace, cannot be replaced by, and do not compete
> with CKRM.  Rather they cooperate with CKRM, and represent one more
> place, along side network drivers, schedulers and memory allocators,
> that eventually will want to respect CKRM service levels.
> The point of _this_ subthread was to consider whether this could more or
> less entirely be done in user space.  The two aspects even of Simon's
> current proposal that I don't see can be done in user space are the
> migration, and the permission model.

Well, the thing is, CKRM essentially has the cross-resource bits and
makes up some group that can be joined and departed from and inherited
and so on with all the right knobs. So the question is "what does CKRM
lack that cpusets needs?" It sounds to me like the major point missing
is "nobody else can touch this cpu" if I read cpusets properly.


-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Thu Sep 25 02:23:12 2003

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:17 EST