On new machines with gobloads of memory and cpu cores, but slow swap
on spinning rust we need to limit the runtime a bit for sanity.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Much better at hitting the list corruption here on my machines
than what we have thus far.
Note that somehow I just can't reproduce the bug any more. No idea
why. But I guess it's time to simply push this pile out.
v2: Limit threads and rounds to something reasonable.
v3: Use igt_permute_array to avoid EINVAL due to duplicated bo.
v4:
- Add a variant of the forked tests with multiple drm fds.
- Tune the swapped forked tests a bit to complete in a reasonable
amount of time.
v5: Add some memory pressure from the cpu by using cpu mmaps (which
directly hit shmem, so bypass gem completely).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This turned out to be the reason one one of my tests was hitting
the list corruption bug - we need a good deal more memory pressure.
So I'll now add a new testcase for that.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also I've stumbled over igt_fixture again. Somehow gcc loves to wreak
havoc with stack variables set up in igt_fixtures ... Duct-tape in the
form of moving fd out to global scope applied.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Exercise the eviction logic. This is just a naive test to ensure that we
can evict old buffers to accommodate new batches, and in the process
trigger the evict everything logic.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
