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

[Caz Yokoyama]

On Fri, 2019-02-22 at 08:12 -0800, Ashutosh Dixit wrote:
> On Thu, Feb 21 2019 at 07:03:57 PM, Caz Yokoyama <
> caz.yokoyama at intel.com> wrote:
> >  	__igt_waitchildren();
> > -	igt_assert(!mlock(can_mlock, *can_mlock));
> 
> This is also wrong. The parent process needs to lock the memory for
> the
> calculation of the amount of locked memory to be correct. Also 
I answered in my commit message as below.

When the parent process mlocks, i.e.,
  igt_assert(!mlock(can_mlock, *can_mlock));
most likely killed.

"most likely" is not correct". "100% of probability" is. 

With the bug, both parent and child mlock 8 times far beyond location.
mlock() may fail because it may beyond mmaped area.

With fixing the bug, the child updates (*can_mlock). Then the parent
mlocks(*can_mlock) and killed by OOM.

Only solution I found is 1) the parent does not mlock(*can_mlock),
2) mlock 252mb less memory.

BTW, dmesg has

[ 4605.251250]
[   8318]     0  8318   497037   315802  2768896      194          1000
i915_suspend
[ 4605.251252]
[   8320]     0  8320   497037   103550  1056768      194          1000
i915_suspend
[ 4605.251254] Out of memory: Kill process 8318 (i915_suspend) score
1317 or sacrifice child
[ 4605.251267] Killed process 8320 (i915_suspend) total-vm:1988148kB,
anon-rss:0kB, file-rss:0kB, shmem-rss:414200kB
[ 4605.251470] oom_reaper: reaped process 8320 (i915_suspend), now
anon-rss:0kB, file-rss:0kB, shmem-rss:414200kB
[ 4605.251560] Purging GPU memory, 0 pages freed, 2327 pages still
pinned.
[ 4605.251563] 1 and 0 pages still available in the bound and unbound
GPU page lists.
 
> explains
> why this tests runs for so long with this patch.
Correction. It runs 7-9 sec. I did not kill X server.

I'll do no further investigation for this test because this is
disabled.
-caz