Re: [RFC/PATCH] cpuset: cpuset irq affinities

[Paul Jackson <pj@sgi.com>]

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