[PATCH] drm/ttm: WIP limit the TTM pool to 32bit CPUs

[Christian König]

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 x86 at kernel.org?

Thanks,
Christian