dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Oded Gabbay <oded.gabbay@amd.com>,
	dri-devel@lists.freedesktop.org, Alexander.Deucher@amd.com
Subject: Re: [PATCH 0/9] Replace use of radeon_sa with a new sub allocator
Date: Wed, 31 Dec 2014 14:49:47 +0100	[thread overview]
Message-ID: <54A3FEFB.3010407@amd.com> (raw)
In-Reply-To: <1420033167-15565-1-git-send-email-oded.gabbay@amd.com>

Am 31.12.2014 um 14:39 schrieb Oded Gabbay:
> Background:
>
> amdkfd needs GART memory for several things, such as runlist packets,
> MQDs, HPDs and more. Unfortunately, all of this memory must be always
> pinned (due to several reasons which were discussed during the
> initial review of amdkfd).

In general seems to be a good idea, but so far I still don't have seen a 
good explanation why all those memory must be pinned. So please 
summarize that one once more.

Regards,
Christian.

>
> Current Solution:
>
> The current (short/mid-term) solution that was proposed by Jerome.G, is
> to limit the amount of memory to a small size, roughly 4MB and allocate
> this buffer at the start of the GART. To accomodate this, amdkfd has
> two kernel module parameters, maximum number of HSA processes and
> maximum number of queues per process, which require under 4MB of GART
> memory when using their defaults, 32 and 128 respectively.
>
> Until now, amdkfd used the radeon sub-allocator module (radeon_sa)
> to handle the sub-allocation of memory from this large buffer to
> different modules inside the amdkfd.
>
> However, while running OpenCL conformance test suite, we found that
> radeon_sa module is not suitable for this kind of task, due to its
> design:
> 1. Every allocation increments its interal pointer so the next
> allocation is *always* done ahead of the previous allocation. This
> causes the internal pointer to wrap-around when it reaches the end of
> the buffer.
>
> 2. When encoutering an area that is already allocated, the module
> waits for that area to be freed. If it is not freed in a timely manner
> (or has no fence), the allocation fails. Simply put, it can't "skip"
> the allocated area.
>
> Now, this is most probably good for graphics, but for amdkfd needs,
> the combination of the two behaviors mentioned above eventually causes
> a denial-of-service. This is because some memory allocations
> are *always* present and *never* freed (such as HPDs).
> Therefore, given enough time and workload, the radeon_sa eventually
> wraps around, encounters an already allocated area and gets stuck.
>
> Proposed new solution:
>
> To solve this, I have written a simple sub-allocator module inside
> amdkfd. It allocates fixed-size contiguous chunks (1 or more) and uses
> a bitmap to manage the allocations. The next allocation is always
> being searched for from the start of the GART buffer, and the module
> knows how to skip allocated chunks.
>
> Because most allocations are MQDs, and MQDs are 512 Bytes in size, I
> set the default chunk size to be 512 Bytes.
>
> The basic GART memory allocation is still being done in the
> amdkfd <--> radeon interface, and it still occupies less than 4MB.
>
> I have chosen to implement a new allocator instead of changing
> radeon_sa because the behavior of radeon_sa is very appropriate for
> graphics, where allocations do not stay forever. Also, amdkfd doesn't
> actually need the flexibility and features radeon_sa provides.
>
> 	Oded
>
> Oded Gabbay (9):
>    drm/amd: Add new kfd-->kgd interface for gart usage
>    drm/radeon: Impl. new gtt allocate/free functions
>    drm/amdkfd: Add gtt sa related data to kfd_dev struct
>    drm/amdkfd: Add kfd gtt sub-allocator functions
>    drm/amdkfd: Fixed calculation of gart buffer size
>    drm/amdkfd: Allocate gart memory using new interface
>    drm/amdkfd: Using new gtt sa in amdkfd
>    drm/radeon: Remove old radeon_sa usage from kfd-->kgd interface
>    drm/amd: Remove old radeon_sa funcs from kfd-->kgd interface
>
>   drivers/gpu/drm/amd/amdkfd/kfd_device.c            | 217 ++++++++++++++++++++-
>   .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  |  23 +--
>   drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c      |  41 ++--
>   drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c       |  16 +-
>   drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c    |  10 +-
>   drivers/gpu/drm/amd/amdkfd/kfd_priv.h              |  28 ++-
>   drivers/gpu/drm/amd/include/kgd_kfd_interface.h    |  23 +--
>   drivers/gpu/drm/radeon/radeon_kfd.c                | 128 ++++++------
>   8 files changed, 329 insertions(+), 157 deletions(-)
>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2014-12-31 13:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-31 13:39 [PATCH 0/9] Replace use of radeon_sa with a new sub allocator Oded Gabbay
2014-12-31 13:39 ` [PATCH 1/9] drm/amd: Add new kfd-->kgd interface for gart usage Oded Gabbay
2014-12-31 13:39 ` [PATCH 2/9] drm/radeon: Impl. new gtt allocate/free functions Oded Gabbay
2014-12-31 13:39 ` [PATCH 3/9] drm/amdkfd: Add gtt sa related data to kfd_dev struct Oded Gabbay
2014-12-31 13:39 ` [PATCH 4/9] drm/amdkfd: Add kfd gtt sub-allocator functions Oded Gabbay
2014-12-31 13:39 ` [PATCH 5/9] drm/amdkfd: Fixed calculation of gart buffer size Oded Gabbay
2014-12-31 13:39 ` [PATCH 6/9] drm/amdkfd: Allocate gart memory using new interface Oded Gabbay
2014-12-31 13:39 ` [PATCH 7/9] drm/amdkfd: Using new gtt sa in amdkfd Oded Gabbay
2014-12-31 13:39 ` [PATCH 8/9] drm/radeon: Remove old radeon_sa usage from kfd-->kgd interface Oded Gabbay
2014-12-31 13:39 ` [PATCH 9/9] drm/amd: Remove old radeon_sa funcs " Oded Gabbay
2014-12-31 13:49 ` Christian König [this message]
2014-12-31 14:06   ` [PATCH 0/9] Replace use of radeon_sa with a new sub allocator Oded Gabbay
2014-12-31 17:07     ` Christian König
2015-01-01  7:46       ` Oded Gabbay
2015-01-06 16:51 ` Alex Deucher

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=54A3FEFB.3010407@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=oded.gabbay@amd.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