Re: [Lse-tech] Re: CPUSET Proposal

From: Hubertus Franke <>
Date: 2003-09-25 23:11:00
Paul Jackson wrote:

>>This sounds like it has progressively more commonality with CKRM; the
>>notion is of a workclass, not of a purely cpu-oriented notion.
>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.
That is correct (assuming slight modification of the schedulers 
qualifies as a hook).

>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.
Yes, to my understanding of cpusets (and I haven't looked into it with 
great detail) its a
virtualization layer above physical binding. One really doesn't care to 
which CPU a process is
bound as long as it is bound to one. One might care that tasks are 
constraint to a particular
number of tasks and not beyond, thus leading to the partitioning 
So I agree here with Paul that it addresses more a physical separation 
of processes, or say
partitioning of machine which CKRM is targeted towards resource 
utilization within a class.
Just like cpu_affinity, CKRM could tolerate cpusets.

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

-- Hubertus Franke     ( CKRM team )

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Thu Sep 25 09:17:20 2003

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