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

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

On 4/22/26 09:32, Tvrtko Ursulin wrote:
> 
> On 21/04/2026 02:26, Matthew Brost wrote:
>> Triggering kswap at an order higher than beneficial_order makes little
>> sense, as the driver has already indicated the optimal order at which
>> reclaim is effective. Similarly, issuing direct reclaim or triggering
>> kswap at a lower order than beneficial_order is ineffective, since the
>> driver does not benefit from reclaiming lower-order pages.
>>
>> As a result, direct reclaim should only be issued with __GFP_NORETRY at
>> exactly beneficial_order, or as a fallback, direct reclaim without
>> __GFP_NORETRY at order 0 when failure is not an option.
>>
>> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>> Cc: Carlos Santa <carlos.santa@intel.com>
>> Cc: Christian Koenig <christian.koenig@amd.com>
>> Cc: Huang Rui <ray.huang@amd.com>
>> Cc: Matthew Auld <matthew.auld@intel.com>
>> Cc: Matthew Brost <matthew.brost@intel.com>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Cc: Maxime Ripard <mripard@kernel.org>
>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: David Airlie <airlied@gmail.com>
>> Cc: Simona Vetter <simona@ffwll.ch>
>> CC: dri-devel@lists.freedesktop.org
>> Cc: Daniel Colascione <dancol@dancol.org>
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> ---
>>   drivers/gpu/drm/ttm/ttm_pool.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
>> index 26a3689e5fd9..8425dbcc6c68 100644
>> --- a/drivers/gpu/drm/ttm/ttm_pool.c
>> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
>> @@ -165,8 +165,8 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t gfp_flags,
>>        * Do not add latency to the allocation path for allocations orders
>>        * device tolds us do not bring them additional performance gains.
>>        */
>> -    if (beneficial_order && order > beneficial_order)
>> -        gfp_flags &= ~__GFP_DIRECT_RECLAIM;
>> +    if (order && beneficial_order && order != beneficial_order)
>> +        gfp_flags &= ~__GFP_RECLAIM;
>>         if (!ttm_pool_uses_dma_alloc(pool)) {
>>           p = alloc_pages_node(pool->nid, gfp_flags, order);
> 
> I missed this conversation so don't know if this was discussed -
> having less of 64k pages is not a concern? I mean slightly higher TLB pressure etc on hardware which supports this PTE size.

At least for AMD GPUs 64k doesn't matter at all.

There was a large push from the Windows side to use that size, but we have more than enough evidence to prove that this size is actually completely nonsense for almost all use cases.

I have no idea how we ended up with that in the first place.

It could be that there is still HW out there which can only handle that size, but in that case such HW should just set beneficial_order to 64k.

> Also, does clearing __GFP_RECLAIM disable compaction completely and is that wanted?

Oh good point, most likely not.

Regards,
Christian.

> 
> Regards,
> 
> Tvrtko
>