[igt-dev] [PATCH] Add a light version of gem_exec_create at forked

[Chris Wilson]

Quoting Ashutosh Dixit (2019-03-06 04:32:58)
> On Tue, 05 Mar 2019 00:42:07 -0800,
> Chris Wilson wrote:
> > 
> > Quoting Swathi Dhanavanthri (2019-03-05 01:16:55)
> > >     igt at gem-exec-create@forked runs a single uniterrupted loop for as long
> > >     as the timeout specified ie 150s. Reducing this to 15s.
> > 
> > There is a light version already. The real question is this heavy
> > enough? What more can we do to induce fault handling along these paths
> > in the kernel? Run a pagecache hog in the background? Use
> > faultinjection?
> 
> From these comments (and also from a limited understanding of the source
> code for the test due to the deferred free's) it appeared that this test is
> being run for so long so that it can exhaust system memory. But we just ran
> the test with 'top' on and we don't see the system memory go down at
> all. If that is indeed the case then what is the point of running this test
> for so long? Thanks!

Yes, at one point it did exhaust memory. And so we imposed some back
pressure on the object creation to avoid that. But it should still be
possible to generate high enough system utilisation that prevents the
freelist from being reaped and so see artifacts during this test.

The first step would be to reduce the memory on the system,

locked = intel_get_pinnable_memory();
munmap(locked + *locked - 128<<20, 128<<20);

and run a one or more memory hogs in the background (see
background_fs()).

The second challenge is detecting when we hit a certain threshold to
be interesting. That's more or less a cycle or two after kswapd kicks
in, but for the purposes of this test can be just an indication that we
hit i915_gem_shrink. For that adding a metric to
debugfs/i915_shrinker_info would seem to be useful.
-Chris