Re: [Lse-tech] Re: CPUSET Proposal

[Hubertus Franke <frankeh@watson.ibm.com>]

Sylvain Jeaugey wrote:

>On Thu, 25 Sep 2003, Hubertus Franke wrote:
>
>  
>
>>Again, I see cpusets and CKRM as addressing two orthogonal issues wrt to 
>>cpu's
>>
>>cpusets  (partitioning in space)   with hierarchies
>>CKRM  (time partitioning)         how much of  time does a class get...
>>    
>>
>We do agree. We took a look at CKRM and that is the conclusion we 
>achieved. At first sight, it could look like the goal are the same -and in 
>some points it is- but the two approaches are different. It looks 
>like it would be better to combine them rather to try to merge them.
>
>Sylvain
>
>
>  
>
Correct.  These are both worthwhile efforts and they do different things.
A combination of  both at some point (not now) should be investigated.
On the CPU front, which cpusets at this point provide its simply orthogonal.

cpusets provide you means to lock process down to cpus through some
abstraction/virtual layer that does not determine the exact cpu but 
guarantees that
some cpu will be choosen to represent that number.

This is analogous to MPI applications which provide communicators which 
effectively
are "cpusets" in the broader sense. On top of that they provide topology 
information
as such..

Actually I don't see why CKRM can't enforce class shares on top of cpu sets.
They simply don't need to know about each others presense. CKRM through
its loadbalancing algorithm enforces shares for SMPs while at the same time
observes cpu_affinity constraints, which effectively cpusets boil down 
to ....

So  "combine" is the correct wording here....

-- Hubertus Franke   (CKRM team)