linux-kernel - Re: [ckrm-tech] [PATCH 1/9] Containers (V9): Basic container framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070501114030.62b85494.pj@sgi.com>
Date:	Tue, 1 May 2007 11:40:30 -0700
From:	Paul Jackson <pj@....com>
To:	balbir@...ux.vnet.ibm.com
Cc:	menage@...gle.com, vatsa@...ibm.com,
	ckrm-tech@...ts.sourceforge.net, balbir@...ibm.com,
	haveblue@...ibm.com, xemul@...ru, dev@...ru,
	containers@...ts.osdl.org, devel@...nvz.org, ebiederm@...ssion.com,
	mbligh@...gle.com, rohitseth@...gle.com, serue@...ibm.com,
	akpm@...ux-foundation.org, svaidy@...ux.vnet.ibm.com,
	linux-kernel@...r.kernel.org
Subject: Re: [ckrm-tech] [PATCH 1/9] Containers (V9): Basic container
 framework

  [[ 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:
	http://lkml.org/lkml/2007/4/29/66

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.

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