Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > --- > 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
