From: Arunpravin <arunpravin.paneerselvam@amd.com>
To: Matthew Auld <matthew.auld@intel.com>,
dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
amd-gfx@lists.freedesktop.org
Cc: alexander.deucher@amd.com, tzimmermann@suse.de,
jani.nikula@linux.intel.com, christian.koenig@amd.com,
daniel@ffwll.ch
Subject: Re: [PATCH 5/8] drm: Implement method to free unused pages
Date: Tue, 9 Nov 2021 19:36:52 +0530 [thread overview]
Message-ID: <8e00b333-b1fe-9136-0fb5-a154bbbf5858@amd.com> (raw)
In-Reply-To: <e7a84d81-c069-ad2d-6b40-3e7574d0955a@intel.com>
On 04/11/21 12:46 am, Matthew Auld wrote:
> On 25/10/2021 14:00, Arunpravin wrote:
>> On contiguous allocation, we round up the size
>> to the *next* power of 2, implement a function
>> to free the unused pages after the newly allocate block.
>>
>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>
> Ideally this gets added with some user, so we can see it in action?
> Maybe squash the next patch here?
[Arun] ok
>
>> ---
>> drivers/gpu/drm/drm_buddy.c | 103 ++++++++++++++++++++++++++++++++++++
>> include/drm/drm_buddy.h | 4 ++
>> 2 files changed, 107 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>> index 9d3547bcc5da..0da8510736eb 100644
>> --- a/drivers/gpu/drm/drm_buddy.c
>> +++ b/drivers/gpu/drm/drm_buddy.c
>> @@ -284,6 +284,109 @@ static inline bool contains(u64 s1, u64 e1, u64 s2, u64 e2)
>> return s1 <= s2 && e1 >= e2;
>> }
>>
>> +/**
>> + * drm_buddy_free_unused_pages - free unused pages
>> + *
>> + * @mm: DRM buddy manager
>> + * @actual_size: original size requested
>> + * @blocks: output list head to add allocated blocks
>> + *
>> + * For contiguous allocation, we round up the size to the nearest
>> + * power of two value, drivers consume *actual* size, so remaining
>> + * portions are unused and it can be freed.
>> + *
>> + * Returns:
>> + * 0 on success, error code on failure.
>> + */
>> +int drm_buddy_free_unused_pages(struct drm_buddy_mm *mm,
>
> drm_buddy_block_trim?
[Arun] ok
>
>> + u64 actual_size,
>
> new_size?
[Arun] ok
>
>> + struct list_head *blocks)
>> +{
>> + struct drm_buddy_block *block;
>> + struct drm_buddy_block *buddy;
>> + u64 actual_start;
>> + u64 actual_end;
>> + LIST_HEAD(dfs);
>> + u64 count = 0;
>> + int err;
>> +
>> + if (!list_is_singular(blocks))
>> + return -EINVAL;
>> +
>> + block = list_first_entry_or_null(blocks,
>> + struct drm_buddy_block,
>> + link);
>> +
>> + if (!block)
>> + return -EINVAL;
>
> list_is_singular() already ensures that I guess?
[Arun] yes it checks the list empty status, I will remove 'if (!block)'
check
>
>
>> +
>> + if (actual_size > drm_buddy_block_size(mm, block))
>> + return -EINVAL;
>> +
>> + if (actual_size == drm_buddy_block_size(mm, block))
>> + return 0;
>
> Probably need to check the alignment of the actual_size, and also check
> that it is non-zero?
[Arun] ok
>
>> +
>> + list_del(&block->link);
>> +
>> + actual_start = drm_buddy_block_offset(block);
>> + actual_end = actual_start + actual_size - 1;
>> +
>> + if (drm_buddy_block_is_allocated(block))
>
> That should rather be a programmer error.
[Arun] ok, I will check for the allocation status and return -EINVAL if
the block is not allocated.
>
>> + mark_free(mm, block);
>> +
>> + list_add(&block->tmp_link, &dfs);
>> +
>> + while (1) {
>> + block = list_first_entry_or_null(&dfs,
>> + struct drm_buddy_block,
>> + tmp_link);
>> +
>> + if (!block)
>> + break;
>> +
>> + list_del(&block->tmp_link);
>> +
>> + if (count == actual_size)
>> + return 0;
>
>
> Check for overlaps somewhere here to avoid needless searching and splitting?
[Arun] ok
>
>> +
>> + if (contains(actual_start, actual_end, drm_buddy_block_offset(block),
>> + (drm_buddy_block_offset(block) + drm_buddy_block_size(mm, block) - 1))) {
>
> Could maybe record the start/end for better readability?
[Arun] ok
>
>> + BUG_ON(!drm_buddy_block_is_free(block));
>> +
>> + /* Allocate only required blocks */
>> + mark_allocated(block);
>> + mm->avail -= drm_buddy_block_size(mm, block);
>> + list_add_tail(&block->link, blocks);
>> + count += drm_buddy_block_size(mm, block);
>> + continue;
>> + }
>> +
>> + if (drm_buddy_block_order(block) == 0)
>> + continue;
>
> Should be impossible with overlaps check added.
[Arun] yes, I will remove
>
>> +
>> + if (!drm_buddy_block_is_split(block)) {
>
> That should always be true.
[Arun] ok
>
>> + err = split_block(mm, block);
>> +
>> + if (unlikely(err))
>> + goto err_undo;
>> + }
>> +
>> + list_add(&block->right->tmp_link, &dfs);
>> + list_add(&block->left->tmp_link, &dfs);
>> + }
>> +
>> + return -ENOSPC;
>
>
> Would it make sense to factor out part of the alloc_range for this? It
> looks roughly the same.
[Arun] This function gets called for non-range allocations (0..max_size)
as well on contiguous allocation. alloc_range() is called only for range
allocations.
>
>> +
>> +err_undo:
>> + buddy = get_buddy(block);
>> + if (buddy &&
>> + (drm_buddy_block_is_free(block) &&
>> + drm_buddy_block_is_free(buddy)))
>> + __drm_buddy_free(mm, block);
>> + return err;
>
>
> Where do we add the block back to the original list? Did we not just
> leak it?
[Arun] we are adding back to the original list if contains() check
becomes true. we are adding all the blocks within the actual_start and
actual_end, and remaining blocks are freed (added to free list).
>
>
>> +}
>> +EXPORT_SYMBOL(drm_buddy_free_unused_pages);
>> +
>> static struct drm_buddy_block *
>> alloc_range(struct drm_buddy_mm *mm,
>> u64 start, u64 end,
>> diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
>> index cd8021d2d6e7..1dfc80c88e1f 100644
>> --- a/include/drm/drm_buddy.h
>> +++ b/include/drm/drm_buddy.h
>> @@ -145,6 +145,10 @@ int drm_buddy_alloc(struct drm_buddy_mm *mm,
>> struct list_head *blocks,
>> unsigned long flags);
>>
>> +int drm_buddy_free_unused_pages(struct drm_buddy_mm *mm,
>> + u64 actual_size,
>> + struct list_head *blocks);
>> +
>> void drm_buddy_free(struct drm_buddy_mm *mm, struct drm_buddy_block *block);
>>
>> void drm_buddy_free_list(struct drm_buddy_mm *mm, struct list_head *objects);
>>
next prev parent reply other threads:[~2021-11-09 13:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 13:00 [PATCH 3/8] drm: implement top-down allocation method Arunpravin
2021-10-25 13:00 ` [PATCH 4/8] drm/i915: add top-down alloc support to i915 Arunpravin
2021-10-25 13:00 ` [PATCH 5/8] drm: Implement method to free unused pages Arunpravin
2021-11-03 19:16 ` Matthew Auld
2021-11-09 14:06 ` Arunpravin [this message]
2021-10-25 13:00 ` [PATCH 6/8] drm/i915: add free_unused_pages support to i915 Arunpravin
2021-11-03 19:18 ` Matthew Auld
2021-11-08 22:04 ` Arunpravin
2021-10-25 13:00 ` [PATCH 7/8] drm/amdgpu: move vram inline functions into a header Arunpravin
2021-10-25 13:00 ` [PATCH 8/8] drm/amdgpu: add drm buddy support to amdgpu Arunpravin
2021-11-03 19:25 ` Matthew Auld
2021-11-04 7:34 ` Christian König
2021-11-04 8:49 ` Matthew Auld
2021-11-04 8:54 ` Christian König
2021-11-08 22:08 ` Arunpravin
2021-10-25 13:00 ` [PATCH v2 1/8] drm: move the buddy allocator from i915 into common drm Arunpravin
2021-10-25 13:00 ` [PATCH v2 2/8] drm: improve drm_buddy_alloc function Arunpravin
2021-11-03 18:41 ` Matthew Auld
2021-11-08 19:50 ` Arunpravin
2021-11-15 21:52 ` Arunpravin
2021-11-03 18:44 ` [PATCH 3/8] drm: implement top-down allocation method Matthew Auld
2021-11-08 21:45 ` Arunpravin
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=8e00b333-b1fe-9136-0fb5-a154bbbf5858@amd.com \
--to=arunpravin.paneerselvam@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=matthew.auld@intel.com \
--cc=tzimmermann@suse.de \
/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