From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
To: "Christian König" <christian.koenig@amd.com>,
"Li, Yunxiang (Teddy)" <Yunxiang.Li@amd.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>
Subject: Re: [PATCH v5 4/4] drm/amdgpu: track bo memory stats at runtime
Date: Wed, 23 Oct 2024 08:38:54 +0100 [thread overview]
Message-ID: <cd2b57c6-1947-4dbd-bae8-ecdb2b42de72@igalia.com> (raw)
In-Reply-To: <53382fc0-0686-46af-9285-0cd6aec314ae@amd.com>
On 22/10/2024 17:24, Christian König wrote:
> Am 22.10.24 um 17:17 schrieb Li, Yunxiang (Teddy):
>> [Public]
>>
>>>> +static uint32_t fold_memtype(uint32_t memtype) {
>>> In general please add prefixes to even static functions, e.g.
>>> amdgpu_vm_ or
>>> amdgpu_bo_.
>>>
>>>> + /* Squash private placements into 'cpu' to keep the legacy
>>>> userspace view.
>>> */
>>>> + switch (mem_type) {
>>>> + case TTM_PL_VRAM:
>>>> + case TTM_PL_TT:
>>>> + return memtype
>>>> + default:
>>>> + return TTM_PL_SYSTEM;
>>>> + }
>>>> +}
>>>> +
>>>> +static uint32_t bo_get_memtype(struct amdgpu_bo *bo) {
>>> That whole function belongs into amdgpu_bo.c
>> Do you mean bo_get_memtype or fold_memtype? I debated whether
>> bo_get_memtype should go into amdgpu_vm.c or amdgpu_bo.c, and since
>> it's using fold_memtype and only useful for memory stats because of
>> folding the private placements I just left them here together with the
>> other mem stats code.
>>
>> I can move it to amdgpu_bo.c make it return the memtype verbatim and
>> just fold it when I do the accounting.
>
> I think that folding GDS, GWS and OA into system is also a bug. We
> should really not doing that.
>
> Just wanted to point out for this round that the code to query the
> current placement from a BO should probably go into amdgpu_bo.c and not
> amdgpu_vm.c
>
>>
>>>> + struct ttm_resource *res = bo->tbo.resource;
>>>> + const uint32_t domain_to_pl[] = {
>>>> + [ilog2(AMDGPU_GEM_DOMAIN_CPU)] = TTM_PL_SYSTEM,
>>>> + [ilog2(AMDGPU_GEM_DOMAIN_GTT)] = TTM_PL_TT,
>>>> + [ilog2(AMDGPU_GEM_DOMAIN_VRAM)] = TTM_PL_VRAM,
>>>> + [ilog2(AMDGPU_GEM_DOMAIN_GDS)] = AMDGPU_PL_GDS,
>>>> + [ilog2(AMDGPU_GEM_DOMAIN_GWS)] = AMDGPU_PL_GWS,
>>>> + [ilog2(AMDGPU_GEM_DOMAIN_OA)] = AMDGPU_PL_OA,
>>>> + [ilog2(AMDGPU_GEM_DOMAIN_DOORBELL)] =
>>> AMDGPU_PL_DOORBELL,
>>>> + };
>>>> + uint32_t domain;
>>>> +
>>>> + if (res)
>>>> + return fold_memtype(res->mem_type);
>>>> +
>>>> + /*
>>>> + * If no backing store use one of the preferred domain for basic
>>>> + * stats. We take the MSB since that should give a reasonable
>>>> + * view.
>>>> + */
>>>> + BUILD_BUG_ON(TTM_PL_VRAM < TTM_PL_TT || TTM_PL_VRAM <
>>> TTM_PL_SYSTEM);
>>>> + domain = fls(bo->preferred_domains & AMDGPU_GEM_DOMAIN_MASK);
>>>> + if (drm_WARN_ON_ONCE(&adev->ddev,
>>>> + domain == 0 || --domain >=
>>>> ARRAY_SIZE(domain_to_pl)))
>>> It's perfectly legal to create a BO without a placement. That one
>>> just won't have a
>>> backing store.
>>>
>> This is lifted from the previous change I'm rebasing onto. I think
>> what it’s trying to do is if the BO doesn't have a placement, use the
>> "biggest" (VRAM > TT > SYSTEM) preferred placement for the purpose of
>> accounting. Previously we just ignore BOs that doesn't have a
>> placement. I guess there's argument for going with either approaches.
>
> I was not arguing, I'm simply pointing out a bug. It's perfectly valid
> for bo->preferred_domains to be 0.
>
> So the following WARN_ON() that no bit is set is incorrect.
>
>>
>>>> + return 0;
>>>> + return fold_memtype(domain_to_pl[domain])
>>> That would need specular execution mitigation if I'm not completely
>>> mistaken.
>>>
>>> Better use a switch/case statement.
>>>
>> Do you mean change the array indexing to a switch statement?
>
> Yes.
Did you mean array_index_nospec? Domain is not a direct userspace input
and is calculated from the mask which sanitized to allowed values prior
to this call. So I *think* switch is an overkill but don't mind it
either. Just commenting FWIW.
Regards,
Tvrtko
next prev parent reply other threads:[~2024-10-23 13:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-18 13:33 [PATCH v5 0/4] rework bo mem stats tracking Yunxiang Li
2024-10-18 13:33 ` [PATCH v5 1/4] drm/amdgpu: remove unused function parameter Yunxiang Li
2024-10-22 6:58 ` Christian König
2024-10-18 13:33 ` [PATCH v5 2/4] drm/amdgpu: make drm-memory-* report resident memory Yunxiang Li
2024-10-18 15:39 ` Tvrtko Ursulin
2024-10-22 7:00 ` Christian König
2024-10-18 13:33 ` [PATCH v5 3/4] drm/amdgpu: stop tracking visible memory stats Yunxiang Li
2024-10-22 7:22 ` Christian König
2024-10-18 13:33 ` [PATCH v5 4/4] drm/amdgpu: track bo memory stats at runtime Yunxiang Li
2024-10-22 7:43 ` Christian König
2024-10-22 15:17 ` Li, Yunxiang (Teddy)
2024-10-22 16:24 ` Christian König
2024-10-22 16:46 ` Li, Yunxiang (Teddy)
2024-10-22 17:06 ` Christian König
2024-10-22 17:09 ` Li, Yunxiang (Teddy)
2024-10-23 6:34 ` Christian König
2024-10-23 7:33 ` Tvrtko Ursulin
2024-10-23 7:38 ` Tvrtko Ursulin [this message]
2024-10-23 9:14 ` Christian König
2024-10-23 11:37 ` Tvrtko Ursulin
2024-10-23 12:12 ` Christian König
2024-10-23 12:24 ` Tvrtko Ursulin
2024-10-23 12:56 ` Christian König
2024-10-24 8:29 ` Tvrtko Ursulin
2024-10-23 13:31 ` Li, Yunxiang (Teddy)
2024-10-23 13:40 ` Li, Yunxiang (Teddy)
2024-10-23 14:27 ` Tvrtko Ursulin
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=cd2b57c6-1947-4dbd-bae8-ecdb2b42de72@igalia.com \
--to=tvrtko.ursulin@igalia.com \
--cc=Alexander.Deucher@amd.com \
--cc=Yunxiang.Li@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
/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