[igt-dev] [igt PATCH v2 1/1] lib: Incrementally mlock()

[Chris Wilson]

Quoting Caz Yokoyama (2019-02-22 02:03:57)
> As we already have the previous portion of the mmap mlocked, we only
> need to mlock() the fresh portion for testing available memory.

I liked my v2 much better that avoided the repeated mlock.
 
> Address calculation on mlock is fixed.
> 
> When the parent process mlocks, i.e.,
>   igt_assert(!mlock(can_mlock, *can_mlock));
> most likely killed.
> 
> In suspend.c, OOM kills when 64MB less memory is mlocked.
> 
> This patch does not make the test faster. It runs 300-900sec.
> I recommend followings.
> 
> 1. Run patched i915_suspend at shrink only on full test(shard test ?)
> 2. add lighter test such as 1) mlock 3/4 of avail memory, 2) suspend-resume

That's completely missing the point. The point of the test is what
happens if we hit oom during suspend. If nothing happens during suspend,
it is just yet another suspend.

The complaint for the test was the sheer volume of dmesg spam along with
regularly locking up the system (and if we aren't locking up the system,
the test isn't doing its job...)
-Chris