[lkml]   [2008]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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 <> 1.940.382.4214

     \ /
      Last update: 2008-03-04 07:17    [W:0.021 / U:8.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site