Re: [PATCH 1/3] drm/ttm: Issue direct reclaim at beneficial_order

["Christian König" <christian.koenig@amd.com>]

On 4/30/26 09:59, Thomas Hellström wrote:
> On Thu, 2026-04-30 at 10:11 +1000, Dave Airlie wrote:
>>>
>>> Probably stupid question: for systems like my Lunar Lake Xe2, which
>>> has
>>> unified memory and (IIUC) no special cache-type or write-mode
>>> constraints for GPU mappings, would it be possible to use regular
>>> system-provided pages (e.g. from shmem) instead of going through
>>> the TTM
>>> pool and allow mTHP to provide the aligned and contiguous backing
>>> storage that the GPU wants? Something like GEM has, but maybe
>>> inside the
>>> TTM API?
>>
>> TTM pool doesn't get used for system memory allocations in that case,
>> if you are asking for cached memory.
> 
> Both Lunar Lake and Panther Lake use write-combined memory for buffer
> objects in performance-critical paths. So the pools are indeed getting
> used.
> 
> And while it is possible to change caching on shmem pages if they are
> pinned/unevictable, trying to pool them quickly becomes messy.

Yeah the issue is just that this functionality is strongly x86 specific. From what I know basically every architecture came up with a distinct way of handling this.

We could move all of this behind GFP flags and into proper architecture abstraction in the core memory management.

But while the functionality was basically mandatory 30 years ago by todays standard it has only a handful of use cases left, so I'm not sure if that's really worth the effort.

On the other hand it would indeed make things *much* cleaner and interestingly at least x86 already tracks the UC/WC state in the struct page.

Christian.

> 
> /Thomas
> 
> 
>>
>> Dave.