[lkml]   [2007]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ckrm-tech] [PATCH 1/9] Containers (V9): Basic container framework
    Paul Jackson wrote:
    > [[ I have bcc'd one or more batch scheduler experts on this post.
    > They will know who they are, and should be aware that they are
    > not listed in the public cc list of this message. - pj ]]
    > Balbir Singh, responding to Paul Menage's Container patch set on lkml, wrote:
    >>> +*** notify_on_release is disabled in the current patch set. It may be
    >>> +*** reactivated in a future patch in a less-intrusive manner
    >>> +
    >> Won't this break user space tools for cpusets?
    > Yes - disabling notify_on_release would definitely break some important
    > uses of cpusets. This feature must be reactivated somehow before I'll
    > sign up for putting this patch set in the main line.
    > Actually, after I posted a few days ago in another lkml post:
    > that just the simplest cpuset command:
    > mount -t cpuset cpuset /dev/cpuset
    > mkdir /dev/cpuset/foo
    > echo 0 > /dev/cpuset/foo/mems
    > caused an immediate kernel deadlock (Srivatsa has proposed a fix), it
    > is pretty clear that this container patch set is not getting the cpuset
    > testing it will need for acceptance. That's partly my fault.
    > The batch scheduler folks, such as the variants of PBS, LSF and SGE are
    > major user of cpusets on NUMA hardware.
    > This container based replacement for cpusets isn't ready for the main
    > line until at least one of those schedulers can run through one of
    > their test suites. I hesitate to even acknowledge this, as I might be
    > the only person in a position to make this happen, and my time
    > available to contribute to this patch set has been less than I would
    > like.
    > But if it looks like we have all the pieces in place to base cpusets
    > on containers, with no known regressions in cpuset capability, then
    > we must find a way to ensure that one of these batch schedulers, using
    > cpusets on a NUMA box, still works.

    Would it be possible to extract those test cases and integrate them
    with a testing framework like LTP? Do you have any regression test
    suite for cpusets that can be made available publicly so that
    any changes to cpusets can be validated?

    The reason I ask for the test suite is that I suspect that the
    container framework will evolve further and a reliable testing
    mechanism would be extremely useful.

    Warm Regards,
    Balbir Singh
    Linux Technology Center
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-02 05:49    [W:0.023 / U:16.048 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site