All of lore.kernel.org
 help / color / mirror / Atom feed
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, christian.koenig@amd.com
Subject: Re: [PATCH 3/8] drm: implement top-down allocation method
Date: Tue, 9 Nov 2021 03:15:38 +0530	[thread overview]
Message-ID: <09e9294f-71cb-fa93-4214-0769f7505b0b@amd.com> (raw)
In-Reply-To: <a5fcbbc3-6c06-d676-3403-1e77a04ddde5@intel.com>



On 04/11/21 12:14 am, Matthew Auld wrote:
> On 25/10/2021 14:00, Arunpravin wrote:
>> Implemented a function which walk through the order list,
>> compares the offset and returns the maximum offset block,
>> this method is unpredictable in obtaining the high range
>> address blocks which depends on allocation and deallocation.
>> for instance, if driver requests address at a low specific
>> range, allocator traverses from the root block and splits
>> the larger blocks until it reaches the specific block and
>> in the process of splitting, lower orders in the freelist
>> are occupied with low range address blocks and for the
>> subsequent TOPDOWN memory request we may return the low
>> range blocks.To overcome this issue, we may go with the
>> below approach.
>>
>> The other approach, sorting each order list entries in
>> ascending order and compares the last entry of each
>> order list in the freelist and return the max block.
>> This creates sorting overhead on every drm_buddy_free()
>> request and split up of larger blocks for a single page
>> request.
>>
>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>> ---
>>   drivers/gpu/drm/drm_buddy.c | 42 +++++++++++++++++++++++++++++++------
>>   include/drm/drm_buddy.h     |  1 +
>>   2 files changed, 37 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>> index 406e3d521903..9d3547bcc5da 100644
>> --- a/drivers/gpu/drm/drm_buddy.c
>> +++ b/drivers/gpu/drm/drm_buddy.c
>> @@ -362,6 +362,27 @@ alloc_range(struct drm_buddy_mm *mm,
>>   	return ERR_PTR(err);
>>   }
>>   
>> +static struct drm_buddy_block *
>> +get_maxblock(struct list_head *head)
>> +{
>> +	struct drm_buddy_block *max_block = NULL, *node;
>> +
>> +	max_block = list_first_entry_or_null(head,
>> +					     struct drm_buddy_block,
>> +					     link);
>> +
>> +	if (!max_block)
>> +		return NULL;
>> +
>> +	list_for_each_entry(node, head, link) {
>> +		if (drm_buddy_block_offset(node) >
>> +				drm_buddy_block_offset(max_block))
> 
> Alignment.
[Arun] ok
> 
>> +			max_block = node;
>> +	}
> 
> I suppose there will be pathological cases where this will unnecessarily 
> steal the mappable portion? But in practice maybe this is good enough?
[Arun] we can go with the other approach, sorting each order list
entries in ascending order and compares the last entry of each order
list in the freelist and return the max block. I think this creates
sorting overhead on every drm_buddy_free() request and (max_order -
requested_order) iterations on every top_down allocation request.

With this method, there will be no unnecessary steal of the mappable
portion, but I guess there might be a performance hit.
> 
>> +
>> +	return max_block;
>> +}
>> +
>>   static struct drm_buddy_block *
>>   alloc_from_freelist(struct drm_buddy_mm *mm,
>>   		    unsigned int order,
>> @@ -372,13 +393,22 @@ alloc_from_freelist(struct drm_buddy_mm *mm,
>>   	int err;
>>   
>>   	for (i = order; i <= mm->max_order; ++i) {
>> -		if (!list_empty(&mm->free_list[i])) {
>> -			block = list_first_entry_or_null(&mm->free_list[i],
>> -							 struct drm_buddy_block,
>> -							 link);
>> +		if (flags & DRM_BUDDY_TOPDOWN_ALLOCATION) {
>> +			if (!list_empty(&mm->free_list[i])) {
> 
> AFAIK no need to keep checking list_empty(), below also.
[Arun] ok
> 
>> +				block = get_maxblock(&mm->free_list[i]);
>>   
>> -			if (block)
>> -				break;
>> +				if (block)
>> +					break;
>> +			}
>> +		} else {
>> +			if (!list_empty(&mm->free_list[i])) {
>> +				block = list_first_entry_or_null(&mm->free_list[i],
>> +								 struct drm_buddy_block,
>> +								 link);
>> +
>> +				if (block)
>> +					break;
>> +			}
>>   		}
>>   	}
>>   
>> diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
>> index c7bb5509a7ad..cd8021d2d6e7 100644
>> --- a/include/drm/drm_buddy.h
>> +++ b/include/drm/drm_buddy.h
>> @@ -28,6 +28,7 @@
>>   })
>>   
>>   #define DRM_BUDDY_RANGE_ALLOCATION (1 << 0)
>> +#define DRM_BUDDY_TOPDOWN_ALLOCATION (1 << 1)
>>   
>>   struct drm_buddy_block {
>>   #define DRM_BUDDY_HEADER_OFFSET GENMASK_ULL(63, 12)
>>

WARNING: multiple messages have this Message-ID (diff)
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 3/8] drm: implement top-down allocation method
Date: Tue, 9 Nov 2021 03:15:38 +0530	[thread overview]
Message-ID: <09e9294f-71cb-fa93-4214-0769f7505b0b@amd.com> (raw)
In-Reply-To: <a5fcbbc3-6c06-d676-3403-1e77a04ddde5@intel.com>



On 04/11/21 12:14 am, Matthew Auld wrote:
> On 25/10/2021 14:00, Arunpravin wrote:
>> Implemented a function which walk through the order list,
>> compares the offset and returns the maximum offset block,
>> this method is unpredictable in obtaining the high range
>> address blocks which depends on allocation and deallocation.
>> for instance, if driver requests address at a low specific
>> range, allocator traverses from the root block and splits
>> the larger blocks until it reaches the specific block and
>> in the process of splitting, lower orders in the freelist
>> are occupied with low range address blocks and for the
>> subsequent TOPDOWN memory request we may return the low
>> range blocks.To overcome this issue, we may go with the
>> below approach.
>>
>> The other approach, sorting each order list entries in
>> ascending order and compares the last entry of each
>> order list in the freelist and return the max block.
>> This creates sorting overhead on every drm_buddy_free()
>> request and split up of larger blocks for a single page
>> request.
>>
>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>> ---
>>   drivers/gpu/drm/drm_buddy.c | 42 +++++++++++++++++++++++++++++++------
>>   include/drm/drm_buddy.h     |  1 +
>>   2 files changed, 37 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>> index 406e3d521903..9d3547bcc5da 100644
>> --- a/drivers/gpu/drm/drm_buddy.c
>> +++ b/drivers/gpu/drm/drm_buddy.c
>> @@ -362,6 +362,27 @@ alloc_range(struct drm_buddy_mm *mm,
>>   	return ERR_PTR(err);
>>   }
>>   
>> +static struct drm_buddy_block *
>> +get_maxblock(struct list_head *head)
>> +{
>> +	struct drm_buddy_block *max_block = NULL, *node;
>> +
>> +	max_block = list_first_entry_or_null(head,
>> +					     struct drm_buddy_block,
>> +					     link);
>> +
>> +	if (!max_block)
>> +		return NULL;
>> +
>> +	list_for_each_entry(node, head, link) {
>> +		if (drm_buddy_block_offset(node) >
>> +				drm_buddy_block_offset(max_block))
> 
> Alignment.
[Arun] ok
> 
>> +			max_block = node;
>> +	}
> 
> I suppose there will be pathological cases where this will unnecessarily 
> steal the mappable portion? But in practice maybe this is good enough?
[Arun] we can go with the other approach, sorting each order list
entries in ascending order and compares the last entry of each order
list in the freelist and return the max block. I think this creates
sorting overhead on every drm_buddy_free() request and (max_order -
requested_order) iterations on every top_down allocation request.

With this method, there will be no unnecessary steal of the mappable
portion, but I guess there might be a performance hit.
> 
>> +
>> +	return max_block;
>> +}
>> +
>>   static struct drm_buddy_block *
>>   alloc_from_freelist(struct drm_buddy_mm *mm,
>>   		    unsigned int order,
>> @@ -372,13 +393,22 @@ alloc_from_freelist(struct drm_buddy_mm *mm,
>>   	int err;
>>   
>>   	for (i = order; i <= mm->max_order; ++i) {
>> -		if (!list_empty(&mm->free_list[i])) {
>> -			block = list_first_entry_or_null(&mm->free_list[i],
>> -							 struct drm_buddy_block,
>> -							 link);
>> +		if (flags & DRM_BUDDY_TOPDOWN_ALLOCATION) {
>> +			if (!list_empty(&mm->free_list[i])) {
> 
> AFAIK no need to keep checking list_empty(), below also.
[Arun] ok
> 
>> +				block = get_maxblock(&mm->free_list[i]);
>>   
>> -			if (block)
>> -				break;
>> +				if (block)
>> +					break;
>> +			}
>> +		} else {
>> +			if (!list_empty(&mm->free_list[i])) {
>> +				block = list_first_entry_or_null(&mm->free_list[i],
>> +								 struct drm_buddy_block,
>> +								 link);
>> +
>> +				if (block)
>> +					break;
>> +			}
>>   		}
>>   	}
>>   
>> diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
>> index c7bb5509a7ad..cd8021d2d6e7 100644
>> --- a/include/drm/drm_buddy.h
>> +++ b/include/drm/drm_buddy.h
>> @@ -28,6 +28,7 @@
>>   })
>>   
>>   #define DRM_BUDDY_RANGE_ALLOCATION (1 << 0)
>> +#define DRM_BUDDY_TOPDOWN_ALLOCATION (1 << 1)
>>   
>>   struct drm_buddy_block {
>>   #define DRM_BUDDY_HEADER_OFFSET GENMASK_ULL(63, 12)
>>

WARNING: multiple messages have this Message-ID (diff)
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, christian.koenig@amd.com
Subject: Re: [Intel-gfx] [PATCH 3/8] drm: implement top-down allocation method
Date: Tue, 9 Nov 2021 03:15:38 +0530	[thread overview]
Message-ID: <09e9294f-71cb-fa93-4214-0769f7505b0b@amd.com> (raw)
In-Reply-To: <a5fcbbc3-6c06-d676-3403-1e77a04ddde5@intel.com>



On 04/11/21 12:14 am, Matthew Auld wrote:
> On 25/10/2021 14:00, Arunpravin wrote:
>> Implemented a function which walk through the order list,
>> compares the offset and returns the maximum offset block,
>> this method is unpredictable in obtaining the high range
>> address blocks which depends on allocation and deallocation.
>> for instance, if driver requests address at a low specific
>> range, allocator traverses from the root block and splits
>> the larger blocks until it reaches the specific block and
>> in the process of splitting, lower orders in the freelist
>> are occupied with low range address blocks and for the
>> subsequent TOPDOWN memory request we may return the low
>> range blocks.To overcome this issue, we may go with the
>> below approach.
>>
>> The other approach, sorting each order list entries in
>> ascending order and compares the last entry of each
>> order list in the freelist and return the max block.
>> This creates sorting overhead on every drm_buddy_free()
>> request and split up of larger blocks for a single page
>> request.
>>
>> Signed-off-by: Arunpravin <Arunpravin.PaneerSelvam@amd.com>
>> ---
>>   drivers/gpu/drm/drm_buddy.c | 42 +++++++++++++++++++++++++++++++------
>>   include/drm/drm_buddy.h     |  1 +
>>   2 files changed, 37 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
>> index 406e3d521903..9d3547bcc5da 100644
>> --- a/drivers/gpu/drm/drm_buddy.c
>> +++ b/drivers/gpu/drm/drm_buddy.c
>> @@ -362,6 +362,27 @@ alloc_range(struct drm_buddy_mm *mm,
>>   	return ERR_PTR(err);
>>   }
>>   
>> +static struct drm_buddy_block *
>> +get_maxblock(struct list_head *head)
>> +{
>> +	struct drm_buddy_block *max_block = NULL, *node;
>> +
>> +	max_block = list_first_entry_or_null(head,
>> +					     struct drm_buddy_block,
>> +					     link);
>> +
>> +	if (!max_block)
>> +		return NULL;
>> +
>> +	list_for_each_entry(node, head, link) {
>> +		if (drm_buddy_block_offset(node) >
>> +				drm_buddy_block_offset(max_block))
> 
> Alignment.
[Arun] ok
> 
>> +			max_block = node;
>> +	}
> 
> I suppose there will be pathological cases where this will unnecessarily 
> steal the mappable portion? But in practice maybe this is good enough?
[Arun] we can go with the other approach, sorting each order list
entries in ascending order and compares the last entry of each order
list in the freelist and return the max block. I think this creates
sorting overhead on every drm_buddy_free() request and (max_order -
requested_order) iterations on every top_down allocation request.

With this method, there will be no unnecessary steal of the mappable
portion, but I guess there might be a performance hit.
> 
>> +
>> +	return max_block;
>> +}
>> +
>>   static struct drm_buddy_block *
>>   alloc_from_freelist(struct drm_buddy_mm *mm,
>>   		    unsigned int order,
>> @@ -372,13 +393,22 @@ alloc_from_freelist(struct drm_buddy_mm *mm,
>>   	int err;
>>   
>>   	for (i = order; i <= mm->max_order; ++i) {
>> -		if (!list_empty(&mm->free_list[i])) {
>> -			block = list_first_entry_or_null(&mm->free_list[i],
>> -							 struct drm_buddy_block,
>> -							 link);
>> +		if (flags & DRM_BUDDY_TOPDOWN_ALLOCATION) {
>> +			if (!list_empty(&mm->free_list[i])) {
> 
> AFAIK no need to keep checking list_empty(), below also.
[Arun] ok
> 
>> +				block = get_maxblock(&mm->free_list[i]);
>>   
>> -			if (block)
>> -				break;
>> +				if (block)
>> +					break;
>> +			}
>> +		} else {
>> +			if (!list_empty(&mm->free_list[i])) {
>> +				block = list_first_entry_or_null(&mm->free_list[i],
>> +								 struct drm_buddy_block,
>> +								 link);
>> +
>> +				if (block)
>> +					break;
>> +			}
>>   		}
>>   	}
>>   
>> diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
>> index c7bb5509a7ad..cd8021d2d6e7 100644
>> --- a/include/drm/drm_buddy.h
>> +++ b/include/drm/drm_buddy.h
>> @@ -28,6 +28,7 @@
>>   })
>>   
>>   #define DRM_BUDDY_RANGE_ALLOCATION (1 << 0)
>> +#define DRM_BUDDY_TOPDOWN_ALLOCATION (1 << 1)
>>   
>>   struct drm_buddy_block {
>>   #define DRM_BUDDY_HEADER_OFFSET GENMASK_ULL(63, 12)
>>

  reply	other threads:[~2021-11-08 21:36 UTC|newest]

Thread overview: 58+ 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 ` [Intel-gfx] " Arunpravin
2021-10-25 13:00 ` [PATCH 4/8] drm/i915: add top-down alloc support to i915 Arunpravin
2021-10-25 13:00   ` [Intel-gfx] " Arunpravin
2021-10-25 13:00 ` [PATCH 5/8] drm: Implement method to free unused pages Arunpravin
2021-10-25 13:00   ` [Intel-gfx] " Arunpravin
2021-11-03 19:16   ` Matthew Auld
2021-11-03 19:16     ` Matthew Auld
2021-11-03 19:16     ` [Intel-gfx] " Matthew Auld
2021-11-09 14:06     ` Arunpravin
2021-11-09 14:06       ` [Intel-gfx] " Arunpravin
2021-11-09 14:06       ` Arunpravin
2021-10-25 13:00 ` [PATCH 6/8] drm/i915: add free_unused_pages support to i915 Arunpravin
2021-10-25 13:00   ` [Intel-gfx] " Arunpravin
2021-11-03 19:18   ` Matthew Auld
2021-11-03 19:18     ` Matthew Auld
2021-11-03 19:18     ` [Intel-gfx] " Matthew Auld
2021-11-08 22:04     ` Arunpravin
2021-11-08 22:04       ` [Intel-gfx] " Arunpravin
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   ` [Intel-gfx] " Arunpravin
2021-10-25 13:00 ` [PATCH 8/8] drm/amdgpu: add drm buddy support to amdgpu Arunpravin
2021-10-25 13:00   ` [Intel-gfx] " Arunpravin
2021-11-03 19:25   ` Matthew Auld
2021-11-03 19:25     ` Matthew Auld
2021-11-03 19:25     ` [Intel-gfx] " Matthew Auld
2021-11-04  7:34     ` Christian König
2021-11-04  7:34       ` Christian König
2021-11-04  7:34       ` [Intel-gfx] " Christian König
2021-11-04  8:49       ` Matthew Auld
2021-11-04  8:49         ` Matthew Auld
2021-11-04  8:49         ` [Intel-gfx] " Matthew Auld
2021-11-04  8:54         ` Christian König
2021-11-04  8:54           ` Christian König
2021-11-04  8:54           ` [Intel-gfx] " Christian König
2021-11-08 22:08           ` Arunpravin
2021-11-08 22:08             ` [Intel-gfx] " Arunpravin
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   ` [Intel-gfx] " Arunpravin
2021-10-25 13:00 ` [PATCH v2 2/8] drm: improve drm_buddy_alloc function Arunpravin
2021-10-25 13:00   ` [Intel-gfx] " Arunpravin
2021-11-03 18:41   ` Matthew Auld
2021-11-03 18:41     ` Matthew Auld
2021-11-03 18:41     ` [Intel-gfx] " Matthew Auld
2021-11-08 19:50     ` Arunpravin
2021-11-08 19:50       ` [Intel-gfx] " Arunpravin
2021-11-08 19:50       ` Arunpravin
2021-11-15 21:52       ` Arunpravin
2021-11-15 21:52         ` [Intel-gfx] " Arunpravin
2021-10-25 13:56 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v2,1/8] drm: move the buddy allocator from i915 into common drm Patchwork
2021-11-03 18:44 ` [PATCH 3/8] drm: implement top-down allocation method Matthew Auld
2021-11-03 18:44   ` Matthew Auld
2021-11-03 18:44   ` [Intel-gfx] " Matthew Auld
2021-11-08 21:45   ` Arunpravin [this message]
2021-11-08 21:45     ` Arunpravin
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=09e9294f-71cb-fa93-4214-0769f7505b0b@amd.com \
    --to=arunpravin.paneerselvam@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.