> > >-----Original Message----- >From: Gordon, David S >Sent: Wednesday, July 29, 2015 4:15 PM >To: Chris Wilson; Gore, Tim; Morton, Derek J; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Wood, Thomas >Subject: Re: [PATCH i-g-t] tests/gem_render_linear_blits: Increase min swap required > >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 implementation of the test. Is there an interface it could use to /detect and measure/ when stuff is swapped out? And there is also the problem that when stuff is swapped in and out that we have no control over what goes into the swap memory. It may well be for some other process that is asleep and be nothing to do with the running test. I could rewrite the subtest to allocate a big lump of memory to fill physical memory, then allocate the swap/2 worth of buffer objects but there is no guarantee the buffer objects will go into swap rather than something else. Also the actual workings of the OOM killer are a black art. When exactly does it start killing processes. There does not appear to be a fixed line that could be monitored with intel_get_avail_ram_mb(). And anyway how does intel_get_avail_ram_mb() interact with swap memory? Does it include swap memory? In which case the subtest would always fail. If not how can we tell when swap memory is filling up? Can intel_get_avail_ram_mb() go up due to the system swapping memory out while available swap memory goes down? The subtest is using intel_get_total_swap_mb(). What if there is already stuff in swap? The sysinfo structure appears to have a freeswap field. How about I try the following: 1. Add an intel_get_avail_swap_mb() function 2. Update the test to allocate buffers until half of swap is used then do the blits. (no idea how slow calling intel_get_avail_swap_mb repeatedly will be) //Derek > >.Dave. > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
