[Intel-gfx] [PATCH i-g-t] tests/gem_render_linear_blits: Increase min swap required

Gore, Tim tim.gore at intel.com
Wed Jul 29 08:34:15 PDT 2015


> -----Original Message-----
> From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> Sent: Wednesday, July 29, 2015 4:20 PM
> To: Gordon, David S
> Cc: Gore, Tim; Morton, Derek J; intel-gfx at lists.freedesktop.org; Wood,
> Thomas
> Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_render_linear_blits: Increase
> min swap required
> 
> 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

"we have enough physical and virtual to complete the test" - is the
incorrect assumption. We would have enough space if the test were
able to calculate memory usage accurately enough, but the way the
test calculates memory usage is too imprecise, we don’t allow for any
overhead at all. If overhead > (swap/2 - oom threshold) then we're dead.

 Tim

Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ



More information about the Intel-gfx mailing list