From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
"Rob Clark" <robdclark@gmail.com>
Subject: Re: [PATCH 2/2] drm/amdgpu: add shared fdinfo stats
Date: Tue, 9 Jan 2024 09:30:15 +0000 [thread overview]
Message-ID: <d2f7c614-228d-490c-9317-8eab0d87ee28@linux.intel.com> (raw)
In-Reply-To: <5b231151-45fe-4d65-a9c2-63973267bdba@gmail.com>
On 09/01/2024 07:56, Christian König wrote:
> Am 07.12.23 um 19:02 schrieb Alex Deucher:
>> Add shared stats. Useful for seeing shared memory.
>>
>> v2: take dma-buf into account as well
>>
>> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>> Cc: Rob Clark <robdclark@gmail.com>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 4 ++++
>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++++++++++
>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 6 ++++++
>> 3 files changed, 21 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
>> index 5706b282a0c7..c7df7fa3459f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
>> @@ -97,6 +97,10 @@ void amdgpu_show_fdinfo(struct drm_printer *p,
>> struct drm_file *file)
>> stats.requested_visible_vram/1024UL);
>> drm_printf(p, "amd-requested-gtt:\t%llu KiB\n",
>> stats.requested_gtt/1024UL);
>> + drm_printf(p, "drm-shared-vram:\t%llu KiB\n",
>> stats.vram_shared/1024UL);
>> + drm_printf(p, "drm-shared-gtt:\t%llu KiB\n",
>> stats.gtt_shared/1024UL);
>> + drm_printf(p, "drm-shared-cpu:\t%llu KiB\n",
>> stats.cpu_shared/1024UL);
>> +
>> for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
>> if (!usage[hw_ip])
>> continue;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> index d79b4ca1ecfc..1b37d95475b8 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> @@ -1287,25 +1287,36 @@ void amdgpu_bo_get_memory(struct amdgpu_bo *bo,
>> struct amdgpu_mem_stats *stats)
>> {
>> uint64_t size = amdgpu_bo_size(bo);
>> + struct drm_gem_object *obj;
>> unsigned int domain;
>> + bool shared;
>> /* Abort if the BO doesn't currently have a backing store */
>> if (!bo->tbo.resource)
>> return;
>> + obj = &bo->tbo.base;
>> + shared = (obj->handle_count > 1) || obj->dma_buf;
>
> I still think that looking at handle_count is the completely wrong
> approach, we should really only look at obj->dma_buf.
Yeah it is all a bit tricky with the handle table walk. I don't think it
is even possible to claim it is shared with obj->dma_buf could be the
same process creating say via udmabuf and importing into drm. It is a
wild scenario yes, but it could be private memory in that case. Not sure
where it would leave us if we said this is just a limitation of a BO
based tracking.
Would adding a new category "imported" help?
Hmm or we simply change drm-usage-stats.rst:
"""
- drm-shared-<region>: <uint> [KiB|MiB]
The total size of buffers that are shared with another file (ie. have
more than than a single handle).
"""
Changing ie into eg coule be get our of jail free card to allow the
"(obj->handle_count > 1) || obj->dma_buf;" condition?
Because of the shared with another _file_ wording would cover my wild
udmabuf self-import case. Unless there are more such creative private
import options.
Regards,
Tvrtko
>
> Regards,
> Christian.
>
>> +
>> domain = amdgpu_mem_type_to_domain(bo->tbo.resource->mem_type);
>> switch (domain) {
>> case AMDGPU_GEM_DOMAIN_VRAM:
>> stats->vram += size;
>> if (amdgpu_bo_in_cpu_visible_vram(bo))
>> stats->visible_vram += size;
>> + if (shared)
>> + stats->vram_shared += size;
>> break;
>> case AMDGPU_GEM_DOMAIN_GTT:
>> stats->gtt += size;
>> + if (shared)
>> + stats->gtt_shared += size;
>> break;
>> case AMDGPU_GEM_DOMAIN_CPU:
>> default:
>> stats->cpu += size;
>> + if (shared)
>> + stats->cpu_shared += size;
>> break;
>> }
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>> index d28e21baef16..0503af75dc26 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>> @@ -138,12 +138,18 @@ struct amdgpu_bo_vm {
>> struct amdgpu_mem_stats {
>> /* current VRAM usage, includes visible VRAM */
>> uint64_t vram;
>> + /* current shared VRAM usage, includes visible VRAM */
>> + uint64_t vram_shared;
>> /* current visible VRAM usage */
>> uint64_t visible_vram;
>> /* current GTT usage */
>> uint64_t gtt;
>> + /* current shared GTT usage */
>> + uint64_t gtt_shared;
>> /* current system memory usage */
>> uint64_t cpu;
>> + /* current shared system memory usage */
>> + uint64_t cpu_shared;
>> /* sum of evicted buffers, includes visible VRAM */
>> uint64_t evicted_vram;
>> /* sum of evicted buffers due to CPU access */
>
next prev parent reply other threads:[~2024-01-09 9:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-07 18:02 [PATCH 0/2] fdinfo shared stats Alex Deucher
2023-12-07 18:02 ` [PATCH 1/2] drm: update drm_show_memory_stats() for dma-bufs Alex Deucher
2023-12-13 21:28 ` Felix Kuehling
2024-01-08 17:29 ` Rob Clark
2023-12-07 18:02 ` [PATCH 2/2] drm/amdgpu: add shared fdinfo stats Alex Deucher
2024-01-08 21:27 ` Alex Deucher
2024-01-09 7:56 ` Christian König
2024-01-09 9:30 ` Tvrtko Ursulin [this message]
2024-01-09 12:54 ` Daniel Vetter
2024-01-09 13:25 ` Tvrtko Ursulin
2024-01-09 14:26 ` Daniel Vetter
2024-01-09 14:57 ` Christian König
2024-01-09 15:09 ` Tvrtko Ursulin
2023-12-13 21:13 ` [PATCH 0/2] fdinfo shared stats Alex Deucher
2024-01-05 21:03 ` 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=d2f7c614-228d-490c-9317-8eab0d87ee28@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=robdclark@gmail.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