On 11.08.25 17:16, Thomas Hellström wrote: >> >>> FWIW If I understand the code correctly, i915 bypasses this by >>> setting >>> up user-space mappings not by vm_insert_pfn_prot() but using >>> apply_to_page_range(), mapping the whole bo. >> >> Yeah, that's probably not something we can do. Even filling in 2MiB >> of address space at a time caused performance problems for TTM. > > Wasn't that because of repeated calls to vmf_insert_pfn_prot(), > repeating the caching checks and page-table walk all the time?
Only partially, the main problem was that only a fraction of the BO was actually CPU accessed. So filling in more than faulted was just overhead. > I think apply_to_page_range() should be pretty fast. Also, to avoid > regressions due to changing the number of prefaulted pages, we could > perhaps honor the MADV_RANDOM and MADV_SEQUENTIAL advises for UMD to > use; one faulting a single page only, one faulting the whole bo Ah! In my thinking apply_to_page_range() would always fault in the whole BO, if that still works for only a partial range than that should be ok. > , but > also see below: > >> >> We should probably just drop overriding the attributes in >> vmf_insert_pfn_prot(). > > I think either solution will see resistance with arch people. We should > probably involve them in the discussion. Any specific person I should CC or just x...@kernel.org? Thanks, Christian
