Messages in this thread | | | Date | Tue, 4 Mar 2008 00:15:07 -0600 | From | Paul Jackson <> | Subject | Re: [RFC/PATCH] cpuset: cpuset irq affinities |
| |
Paul M wrote: > One of the arguments that you posted against his proposal was that > this would break due to the memory overlap requirements of > mem_exclusive cpusets.
There were three concerns I had with his proposal -- (1) it conflicted with memory placement, (2) it conflicted with cpu placement (sched domain definition) and (3) it broke the conventional cpuset hierarchy configuration on which users have come to depend.
Separating cpus and memory as distinct cgroup subsystems wouldn't help much; there's still (2) and (3). And in the legacy /dev/cpuset interface, cpus and memory remain together, whether or not cgroups enables them to be separate.
> I'm sure if cpusets were being developed today on top of cgroups, > rather than being its inspiration, there would be no good reason to > have the memory mask assignment and the cpu mask assignment be part of > the same subsystem
Perhaps ... though they work together rather well in practice, perhaps because CPUs and memory banks usually are physically associated; selecting which CPUs to use and which memory banks to use really is not an independent choice, on most hardware.
Now however the shoe is on the other foot. Is there a good reason to separate them ... an actual would-be user, or actual problems inflicted on current users due to the lack of this split?
If there's just a rare occassion such an independently split CPU and Memory hiearchy, one can still use the current combined cpuset implementation, just with a less natural cpuset hierarchy (more leaf node cpusets, representing the cross product of interesting CPU subsets and interesting memory node subsets.) If some specified users start doing this routinely, then that gets sufficiently cumbersome that it's worth trying to remedy.
As usual, I seem to be counseling resisting adding code, complexity and incompatible change, without actual need, beyond just increased conceptual sophistication.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.940.382.4214
| |