[Intel-gfx] [PATCH i-g-t 1/3] i915/gem_userptr_blits: Only mlock the memfd once, not the arena

[Mika Kuoppala]

Chris Wilson <chris at chris-wilson.co.uk> writes:

> We multiply the memfd 64k to create a 2G arena which we then attempt to
> write into after marking read-only. Howver, when it comes to unlock the

s/Howver/However

> arena after the test, performance tanks as the kernel tries to resolve
> the 64k repeated mappings onto the same set of pages. (Must not be a
> very common operation!) We can get away with just mlocking the backing
> store to prevent its eviction, which should prevent the arena mapping
> from being freed as well.

hmm should. How are they bound?

-Mika

>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=108887
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> ---
>  tests/i915/gem_userptr_blits.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
> index 909dd19df..c4e60ba92 100644
> --- a/tests/i915/gem_userptr_blits.c
> +++ b/tests/i915/gem_userptr_blits.c
> @@ -1124,7 +1124,7 @@ static void test_readonly(int i915)
>  		*(uint32_t *)(space + offset) = offset;
>  	}
>  	igt_assert_eq_u32(*(uint32_t *)pages, (uint32_t)(total - sz));
> -	igt_assert(mlock(space, total) == 0);
> +	igt_assert(mlock(pages, sz) == 0);
>  	close(memfd);
>  
>  	/* Check we can create a normal userptr bo wrapping the wrapper */
> @@ -1176,6 +1176,7 @@ static void test_readonly(int i915)
>  	}
>  	igt_waitchildren();
>  
> +	munlock(pages, sz);
>  	munmap(space, total);
>  	munmap(pages, sz);
>  }
> -- 
> 2.20.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx