From: Hubertus F. <fr...@wa...> - 2003-09-25 13:14:49
|
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 capabilities. 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 ) |