Quoting Mika Kuoppala (2019-01-16 10:35:59) > 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. To be fair, it is just an optimisation to make sure we can use the whole arena (checking against available address space) and that it won't be change (and be refaulted, so the results should be transparent although expensive) under testing. I can't recall any other reason for sticking mlock in there. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
