lkml.org 
[lkml]   [2008]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: boot cgroup questions
    > This is what I meant by "deeper hierarchies" in the earlier emails.

    These deeper hierarchies create an incompatibility in some common uses
    of cpusets.

    When my example had cpusets A, B and C, that was as stated, not as
    might be modified to X, X/A, X/B and C.

    If the user has or would have setup cpusets A, B and C because that's
    what they needed to manage the CPU and Memory Node placement of their
    tasks, then that's what they might have setup, and there is a good
    chance that they would find the imposition of the extra 'X' cpuset to
    be a problem, to require more code and to be a cause of bugs.

    Adding irqs to the cpuset hierarchy isn't free; it can further overload
    the hierarchy, with "deeper hierarchies" as you state.

    If instead of deeper hierarchies, we allow the same irq to be listed in
    more than one cpuset (unlike tasks, which only get one cpuset) then we
    need some way, independent of the cpuset hierarchy, to determine how to
    resolve conflicts. We can't just add all the cpus together, allowing an
    irq to be directed to any CPU which is listed in any cpuset that
    accepts that irq, because a major use for this is to remove irqs from
    certain realtime CPUs.

    So ... if the natural hierarchy needed to map irqs to CPUs is not a
    subset of the natural hierarchy needed to map tasks to sets of CPUs and
    Nodes, then we either deepen the hierarchy (cross product of the the
    two maps, essentially) or we allow the same irq to be listed in
    multiple cpusets and provide some alternative mechanism, outside the
    hierarchy, to resolve the resulting conflicts in the irq to CPU map.

    --
    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <pj@sgi.com> 1.940.382.4214


    \
     
     \ /
      Last update: 2008-03-12 21:41    [W:2.671 / U:0.340 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site