Re: [PATCH v2] drm/xe: Use DRM_BUDDY_CONTIGUOUS_ALLOCATION for contiguous allocations

["Yadav, Sanjay Kumar" <sanjay.kumar.yadav@intel.com>]

On 10-12-2025 15:55, Matthew Auld wrote:
> On 09/12/2025 17:29, Sanjay Yadav wrote:
>> The VRAM/stolen memory managers do not currently set
>> DRM_BUDDY_CONTIGUOUS_ALLOCATION for contiguous allocations. Enabling
>> this flag activates the buddy allocator's try_harder path, which helps
>> handle fragmented memory scenarios.
>>
>> This enables the __alloc_contig_try_harder fallback in the buddy
>> allocator, allowing contiguous allocation requests to succeed even when
>> memory is fragmented by combining allocations from both(RHS and LHS)
>> sides of a large free block.
>>
>> v2: (Matt B)
>> - Remove redundant logic for rounding allocation size and trimming when
>>    TTM_PL_FLAG_CONTIGUOUS is set, since drm_buddy now handles this when
>>    DRM_BUDDY_CONTIGUOUS_ALLOCATION is enabled
>>
>> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6713
>> Suggested-by: Matthew Auld <matthew.auld@intel.com>
>> Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com>
>> ---
>>   drivers/gpu/drm/xe/xe_ttm_vram_mgr.c | 16 +++-------------
>>   1 file changed, 3 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c 
>> b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
>> index 9f70802fce92..1a819b627afe 100644
>> --- a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
>> +++ b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
>> @@ -82,6 +82,9 @@ static int xe_ttm_vram_mgr_new(struct 
>> ttm_resource_manager *man,
>>       if (place->flags & TTM_PL_FLAG_TOPDOWN)
>>           vres->flags |= DRM_BUDDY_TOPDOWN_ALLOCATION;
>>   +    if (place->flags & TTM_PL_FLAG_CONTIGUOUS)
>> +        vres->flags |= DRM_BUDDY_CONTIGUOUS_ALLOCATION;
>> +
>>       if (place->fpfn || lpfn != man->size >> PAGE_SHIFT)
>>           vres->flags |= DRM_BUDDY_RANGE_ALLOCATION;
>>   @@ -111,25 +114,12 @@ static int xe_ttm_vram_mgr_new(struct 
>> ttm_resource_manager *man,
>>           goto error_unlock;
>>       }
>>   -    if (place->fpfn + (size >> PAGE_SHIFT) != lpfn &&
>> -        place->flags & TTM_PL_FLAG_CONTIGUOUS) {
>> -        size = roundup_pow_of_two(size);
>> -        min_page_size = size;
>> -
>> -        lpfn = max_t(unsigned long, place->fpfn + (size >> 
>> PAGE_SHIFT), lpfn);
>> -    }
>
> lgtm. One thing to consider is whether this might now open us up to:
>
> https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6712
>
> This is likely not an issue for VRAM but stolen can trigger this path 
> and the region size there is pretty small and we heavily use CONTIG 
> for at least fbc IIRC, so this could now be triggerable. I guess lets 
> just wait and see what upstream CI says, but not 100% if something in 
> the wild might hit it even if CI is clean (or perhaps something in 
> internal). If we want to play it safe we could land this after fixing 
> 6712, but up to you (assuming upstream CI is at least happy).
>
> Reviewed-by: Matthew Auld <matthew.auld@intel.com>

Hi Matt A

Thanks for the review and the heads-up about issue #6712! I appreciate 
you pointing out the possible risk with stolen memory and FBC.
I think let's wait and fix #6712 first before landing this patch. Better 
to be safe and avoid introducing any regressions.

-Sanjay

>> -
>>       err = drm_buddy_alloc_blocks(mm, (u64)place->fpfn << PAGE_SHIFT,
>>                        (u64)lpfn << PAGE_SHIFT, size,
>>                        min_page_size, &vres->blocks, vres->flags);
>>       if (err)
>>           goto error_unlock;
>>   -    if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
>> -        if (!drm_buddy_block_trim(mm, NULL, vres->base.size, 
>> &vres->blocks))
>> -            size = vres->base.size;
>> -    }
>> -
>>       if (lpfn <= mgr->visible_size >> PAGE_SHIFT) {
>>           vres->used_visible_size = size;
>>       } else {
>