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]

Date:	Wed, 02 May 2007 09:14:01 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	Paul Jackson <pj@....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

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:
> 	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.
> 

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
	IBM, ISTL
-
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/