Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > Quoting Mika Kuoppala (2019-01-16 09:47:27) >> 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? > > 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@xxxxxxxxxxxxxxx> _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
