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
next prev 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