From: Mario Limonciello <mario.limonciello@amd.com>
To: Yifan Zhang <yifan1.zhang@amd.com>, amd-gfx@lists.freedesktop.org
Cc: Alexander.Deucher@amd.com, Felix.Kuehling@amd.com
Subject: Re: [PATCH] amd/amdkfd: correct mem limit calculation for small APUs
Date: Tue, 2 Sep 2025 23:57:21 -0500 [thread overview]
Message-ID: <11356cde-e7a2-4d34-b067-d38619e02187@amd.com> (raw)
In-Reply-To: <20250901022716.283793-1-yifan1.zhang@amd.com>
On 8/31/2025 9:27 PM, Yifan Zhang wrote:
> Current mem limit check leaks some GTT memory (reserved_for_pt
> reserved_for_ras + adev->vram_pin_size) for small APUs.
>
> Since carveout VRAM is tunable on APUs, there are three case
> regarding the carveout VRAM size relative to GTT:
>
> 1. 0 < carveout < gtt
> apu_prefer_gtt = true, is_app_apu = false
>
> 2. carveout > gtt / 2
> apu_prefer_gtt = false, is_app_apu = false
>
> 3. 0 = carveout
> apu_prefer_gtt = true, is_app_apu = true
>
> It doesn't make sense to check below limitation in case 1
> (default case, small carveout) because the values in the below
> expression are mixed with carveout and gtt.
>
> adev->kfd.vram_used[xcp_id] + vram_needed >
> vram_size - reserved_for_pt - reserved_for_ras -
> atomic64_read(&adev->vram_pin_size)
>
> gtt: kfd.vram_used, vram_needed, vram_size
> carveout: reserved_for_pt, reserved_for_ras, adev->vram_pin_size
>
> In case 1, vram allocation will go to gtt domain, skip vram check
> since ttm_mem_limit check already cover this allocation.
>
> v2: simplify judgement logic (Mario)
You can strip the changelog from the commit message.
>
> Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 44 ++++++++++++++-----
> 1 file changed, 32 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index d478acb4568a..c3b34a410375 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -213,19 +213,35 @@ int amdgpu_amdkfd_reserve_mem_limit(struct amdgpu_device *adev,
> spin_lock(&kfd_mem_limit.mem_limit_lock);
>
> if (kfd_mem_limit.system_mem_used + system_mem_needed >
> - kfd_mem_limit.max_system_mem_limit)
> + kfd_mem_limit.max_system_mem_limit) {
> pr_debug("Set no_system_mem_limit=1 if using shared memory\n");
> + if (!no_system_mem_limit) {
> + ret = -ENOMEM;
> + goto release;
> + }
> + }
>
> - if ((kfd_mem_limit.system_mem_used + system_mem_needed >
> - kfd_mem_limit.max_system_mem_limit && !no_system_mem_limit) ||
> - (kfd_mem_limit.ttm_mem_used + ttm_mem_needed >
> - kfd_mem_limit.max_ttm_mem_limit) ||
> - (adev && xcp_id >= 0 && adev->kfd.vram_used[xcp_id] + vram_needed >
> - vram_size - reserved_for_pt - reserved_for_ras - atomic64_read(&adev->vram_pin_size))) {
> + if (kfd_mem_limit.ttm_mem_used + ttm_mem_needed >
> + kfd_mem_limit.max_ttm_mem_limit) {
> ret = -ENOMEM;
> goto release;
> }
>
> + /*if is_app_apu is false and apu_prefer_gtt is true, it is an APU with
> + * carve out < gtt. In that case, VRAM allocation will go to gtt domain, skip
> + * VRAM check since ttm_mem_limit check already cover this allocation
> + */
> +
> + if (adev && xcp_id >= 0 && (!adev->apu_prefer_gtt || adev->gmc.is_app_apu)) {
> + uint64_t vram_available =
> + vram_size - reserved_for_pt - reserved_for_ras -
> + atomic64_read(&adev->vram_pin_size);
> + if (adev->kfd.vram_used[xcp_id] + vram_needed > vram_available) {
> + ret = -ENOMEM;
> + goto release;
> + }
> + }
> +
> /* Update memory accounting by decreasing available system
> * memory, TTM memory and GPU memory as computed above
> */
> @@ -1627,11 +1643,15 @@ size_t amdgpu_amdkfd_get_available_memory(struct amdgpu_device *adev,
> uint64_t vram_available, system_mem_available, ttm_mem_available;
>
> spin_lock(&kfd_mem_limit.mem_limit_lock);
> - vram_available = KFD_XCP_MEMORY_SIZE(adev, xcp_id)
> - - adev->kfd.vram_used_aligned[xcp_id]
> - - atomic64_read(&adev->vram_pin_size)
> - - reserved_for_pt
> - - reserved_for_ras;
> + if (adev->apu_prefer_gtt && !adev->gmc.is_app_apu)
> + vram_available = KFD_XCP_MEMORY_SIZE(adev, xcp_id)
> + - adev->kfd.vram_used_aligned[xcp_id];
> + else
> + vram_available = KFD_XCP_MEMORY_SIZE(adev, xcp_id)
> + - adev->kfd.vram_used_aligned[xcp_id]
> + - atomic64_read(&adev->vram_pin_size)
> + - reserved_for_pt
> + - reserved_for_ras;
>
> if (adev->apu_prefer_gtt) {
> system_mem_available = no_system_mem_limit ?
prev parent reply other threads:[~2025-09-03 4:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-01 2:27 [PATCH] amd/amdkfd: correct mem limit calculation for small APUs Yifan Zhang
2025-09-03 4:57 ` Mario Limonciello [this message]
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=11356cde-e7a2-4d34-b067-d38619e02187@amd.com \
--to=mario.limonciello@amd.com \
--cc=Alexander.Deucher@amd.com \
--cc=Felix.Kuehling@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=yifan1.zhang@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 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.