lkml.org 
[lkml]   [2007]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ckrm-tech] [PATCH 1/9] Containers (V9): Basic container framework
Paul Jackson wrote:
> Balbir wrote:

>
> 1) Testing batch schedulers against cpusets:
>
> I doubt that the batch scheduler developers would be able to
> extract a cpuset test from their tests, or be able to share it if
> they did. Their tests tend to be large tests of batch schedulers,
> and only incidentally test cpusets -- if we break cpusets,
> in sometimes even subtle ways that they happen to depend on,
> we break them.
>
> Sometimes there is no way to guess exactly what sorts of changes
> will break their code; we'll just have to schedule at least one
> run through one or more of them that rely heavily on cpusets
> before a change as big as rebasing cpusets on containers is
> reasonably safe. This test cycle won't be all that easy, so I'd
> wait until we are pretty close to what we think should be taken
> into the mainline kernel.
>
> I suppose I will have to be the one co-ordinating this test,
> as I am the only one I know with a presence in both camps.
>
> Once this test is done, from then forward, if we break them,
> we'll just have to deal with it as we do now, when the breakage
> shows up well down stream from the main kernel tree, at the point
> that a major batch scheduler release runs into a major distribution
> release containing the breakage. There is no practical way that I
> can see, as an ongoing basis, to continue testing for such breakage
> with every minor change to cpuset related code in the kernel. Any
> breakage found this way is dealt with by changes in user level code.
>
> Once again, I have bcc'd one or more developers of batch schedulers,
> so they can see what nonsense I am spouting about them now ;).
>

That sounds reasonable to me

> 2) Testing cpusets with a specific test.
>
> There I can do better. Attached is the cpuset regression test I
> use. It requires at least 4 cpus and 2 memory nodes to do anything
> useful. It is copyright by SGI, released under GPL license.
>
> This regression test is the primary cpuset test upon which I
> relied during the development of cpusets, and continue to rely.
> Except for one subtle race condition in the test itself, it has
> not changed in the last two to three years.
>
> This test requires no user level code not found in an ordinary
> distro. It does require the taskset and numactl commands,
> for the purposes of testing certain interactions with them.
> It assumes that there are not other cpusets currently setup in
> the system that happen to conflict with the ones it creates.
>
> See further comments within the test script itself.
>

Thanks for the script. Would you like to contribute this script to
LTP for wider availability and testing?

--
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@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: 2007-05-10 06:13    [W:0.061 / U:1.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site