AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Paneer Selvam, Arunpravin" <arunpravin.paneerselvam@amd.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	amd-gfx@lists.freedesktop.org
Cc: christian.koenig@amd.com, alexander.deucher@amd.com,
	matthew.auld@intel.com, felix.kuehling@amd.com,
	mario.limonciello@amd.com
Subject: Re: [PATCH v8 3/3] drm/buddy: Add user for defragmentation
Date: Tue, 5 Mar 2024 16:33:08 +0530	[thread overview]
Message-ID: <aaf76e24-787d-4ca7-b3af-3636d065c1f6@amd.com> (raw)
In-Reply-To: <77148946-83ef-4576-a26b-ec84f9a4c63a@gmail.com>

Hi Christian,

On 3/4/2024 10:09 PM, Christian König wrote:
> Am 04.03.24 um 17:32 schrieb Arunpravin Paneer Selvam:
>> Add amdgpu driver as user for the drm buddy
>> defragmentation.
>>
>> Signed-off-by: Arunpravin Paneer Selvam 
>> <Arunpravin.PaneerSelvam@amd.com>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 +++++++++++++++--
>>   drivers/gpu/drm/drm_buddy.c                  |  1 +
>>   2 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> index e494f5bf136a..cff8a526c622 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>> @@ -533,8 +533,21 @@ static int amdgpu_vram_mgr_new(struct 
>> ttm_resource_manager *man,
>>                          min_block_size,
>>                          &vres->blocks,
>>                          vres->flags);
>> -        if (unlikely(r))
>> -            goto error_free_blocks;
>> +        if (unlikely(r)) {
>> +            if (r == -ENOSPC) {
>> +                drm_buddy_defrag(mm, min_block_size);
>> +                r = drm_buddy_alloc_blocks(mm, fpfn,
>> +                               lpfn,
>> +                               size,
>> +                               min_block_size,
>> +                               &vres->blocks,
>> +                               vres->flags);
>
> That doesn't looks like something we should do.
>
> We might fallback when contiguous memory is requested, but certainly 
> not on normal allocation failure.
yes, defrag here not useful for normal allocations. But worried about 
the bigger min_block_size normal allocations.
In such cases, I think we should move this drm_buddy_defrag() call into 
buddy allocator file. For example if the required
size is 1024KiB and if min_block_size is 256KiB, the allocator first 
tries to find the 1024KiB block, when there is no single 1024KiB block,
the allocator goes one level below in freelist and tries to search for 
two 512KiB blocks and goes on. At one point of time if we have less space,
we might go further levels below to search four 256KiB blocks to satisfy 
the request.

Assuming if the allocator cannot find the first 256KiB block, that time 
I think we might need to merge the two 128KiB blocks
through defragmentation function. And again for the second 256KiB block, 
we might need to call the defragmentation again to
merge two 128KiB blocks or four 64KiB blocks to form minimum alignment 
size of 256KiB. This goes on for the third and fourth
256KiB blocks to complete the required size allocation of 1024KiB. 
Please let me know if my understanding is not correct.

Thanks,
Arun.
>
> Regards,
> Christian.
>
>> +                if (unlikely(r))
>> +                    goto error_free_blocks;
>> +            } else {
>> +                goto error_free_blocks;
>> +            }
>> +        }
>>             if (size > remaining_size)
>>               remaining_size = 0;
>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>> index 40131ed9b0cd..19440f8caec0 100644
>> --- a/drivers/gpu/drm/drm_buddy.c
>> +++ b/drivers/gpu/drm/drm_buddy.c
>> @@ -396,6 +396,7 @@ void drm_buddy_defrag(struct drm_buddy *mm,
>>           }
>>       }
>>   }
>> +EXPORT_SYMBOL(drm_buddy_defrag);
>>     /**
>>    * drm_buddy_free_block - free a block
>


  reply	other threads:[~2024-03-05 11:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-04 16:32 [PATCH v8 1/3] drm/buddy: Implement tracking clear page feature Arunpravin Paneer Selvam
2024-03-04 16:32 ` [PATCH v8 2/3] drm/amdgpu: Enable clear page functionality Arunpravin Paneer Selvam
2024-03-04 16:32 ` [PATCH v8 3/3] drm/buddy: Add user for defragmentation Arunpravin Paneer Selvam
2024-03-04 16:39   ` Christian König
2024-03-05 11:03     ` Paneer Selvam, Arunpravin [this message]
2024-03-05 11:14       ` Paneer Selvam, Arunpravin
2024-03-05 12:11         ` Christian König
2024-03-06 15:45           ` Paneer Selvam, Arunpravin
2024-03-06 15:49 ` [PATCH v8 1/3] drm/buddy: Implement tracking clear page feature Paneer Selvam, Arunpravin
2024-03-06 17:49 ` Matthew Auld
2024-03-07 12:25   ` Paneer Selvam, Arunpravin
2024-03-07 16:38     ` Matthew Auld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aaf76e24-787d-4ca7-b3af-3636d065c1f6@amd.com \
    --to=arunpravin.paneerselvam@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=felix.kuehling@amd.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mario.limonciello@amd.com \
    --cc=matthew.auld@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox