lkml.org 
[lkml]   [2006]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ckrm-tech] [RFC] Resource Management - Infrastructure choices
    Paul M wroteL
    > One of the issues that crops up with it is what do you put in
    > /proc/<pid>/container if there are multiple hierarchies?

    Thanks for your rapid responses - good.

    How about /proc/<pid>/containers being a directory, with each
    controller having one regular file entry (so long as we haven't done
    the multiple controller instances in my item (5)) containing the path,
    relative to some container file system mount point (which container
    mount is up to user space code to track) of the container that contains
    that task?

    Or how about each controller type, such as cpusets, having its own
    /proc/<pid>/<controller-type> file, with no generic file
    /proc</pid>/container at all. Just extend the current model
    seen in /proc/<pid>/cpuset ?

    Actually, I rather like that last alternative - forcing the word
    'container' into these /proc/<pid>/??? pathnames strikes me as
    an exercise in branding, not in technical necessity. But that
    could just mean I am still missing a big fat clue somewhere ...

    Feel free to keep hitting me with clue sticks, as need be.

    It will take a while (as in a year or two) for me and others to train
    all the user level code that 'knows' that cpusets are always mounted at
    "/dev/cpuset" to find the mount point for the container handling
    cpusets anywhere else.

    I knew when I hardcoded the "/dev/cpuset" path in various places
    in user space that I might need to revisit that, but my crystal
    ball wasn't good enough to predict what form this generalization
    would take. So I followed one of my favorite maxims - if you can't
    get it right, at least keep it stupid, simple, so that whomever does
    have to fix it up has the least amount of legacy mechanism to rip out.

    However this fits in nicely with my expectation that we will have
    only limited need, if any, in the short term, to run systems with
    both cpusets and resource groups at the same time. Systems just
    needing cpusets can jolly well continue to mount at /dev/cpuset,
    in perpetuity. Systems needing other or fancier combinations of
    controllers will need to handle alternative mount points, and keep
    track somehow in user space of what's mounted where.

    And while we're here, how about each controller naming itself with a
    well known string compiled into its kernel code, and a file such
    as /proc/containers listing what controllers are known to it? Not
    surprisingly, I claim the word "cpuset" to name the cpuset controller ;)

    --
    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <pj@sgi.com> 1.925.600.0401
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-11-07 21:37    [W:0.032 / U:60.360 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site