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