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

[Matthew Auld <matthew.auld@intel.com>]

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>

> -
>   	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 {