[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:

> Quoting Mika Kuoppala (2019-01-16 09:47:27)
>> 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?
>
> All I'm worried about are the allocs for the pud/pmd etc, which aiui are
> not freed until the pte are removed and the pte shouldn't be reaped
> because the struct page are locked. However, I haven't actually verified
> that mlocking the underlying pages is enough to be sure that the page
> tables of the various mappings are safe from eviction. On the other
> hand, munlock_vma_range doesn't scale to the abuse we put it to, and
> that is causing issues for CI!

If we can dodge it with this, great.
Noticed there is also typo in preceeding code,
the comment when mapping the arena. s/usuable/usable.

Reviewed-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>