On Wed, Jul 29, 2015 at 04:14:55PM +0100, Dave Gordon wrote: > On 29/07/15 14:15, Chris Wilson wrote: > >On Wed, Jul 29, 2015 at 01:10:23PM +0000, Gore, Tim wrote: > >>I don’t see how this implies a kernel bug. It seems like a test problem (my > >>subtest as it happens). I was unaware of Android systems with small swap > >>partitions (or indeed any swap at all). Not sure I can understand the logic of > >>such a tiny swap partition but given the situation, unless we can accurately > >>characterise the memory usage of the test in advance then we have to > >>either skip the test for small swap, or try to monitor memory usage in an > >>ongoing way during the test. > > > >If the system has enough resources to run the test (that is enough > >physical to run an individual batch plus enough swap to hold the rest), > >then the test must not oom. > >-Chris > > The test is deliberately attempting to use enough memory to force > some stuff out to swap, while not hitting a total OOM. That can be a > very narrow window when the swapspace is small; and the test just > guesses in advance how much will do the trick rather than gradually > increasing its demands until it detects that stuff is being swapped. > > So not a kernel bug, but something of a failure in the Pardon? Which part of we have enough physical and virtual to complete the test, but an oom is triggered instead is an incorrect assumption? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
