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) - 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.htmlReceived on Fri Sep 26 08:59:21 2003
This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:18 EST