From: Steven Price <steven.price@arm.com>
To: "Mihail Atanassov" <mihail.atanassov@arm.com>,
"Adrián Martínez Larumbe" <adrian.larumbe@collabora.com>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
"Liviu Dudau" <liviu.dudau@arm.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>
Cc: nd@arm.com, kernel@collabora.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 1/2] drm/panthor: Expose size of driver internal BO's over fdinfo
Date: Fri, 20 Dec 2024 11:08:44 +0000 [thread overview]
Message-ID: <cf8ea27a-f7de-4518-afb1-61fcf5bbb981@arm.com> (raw)
In-Reply-To: <2a7c5a0b-af3f-4f1c-8c77-ab6233afcc76@arm.com>
On 19/12/2024 16:30, Mihail Atanassov wrote:
>
>
> On 18/12/2024 18:18, Adrián Martínez Larumbe wrote:
>> From: Adrián Larumbe <adrian.larumbe@collabora.com>
>>
>> This will display the sizes of kenrel BO's bound to an open file,
>> which are
>> otherwise not exposed to UM through a handle.
>>
>> The sizes recorded are as follows:
>> - Per group: suspend buffer, protm-suspend buffer, syncobjcs
>> - Per queue: ringbuffer, profiling slots, firmware interface
>> - For all heaps in all heap pools across all VM's bound to an open
>> file,
>> record size of all heap chuks, and for each pool the gpu_context BO
>> too.
>>
>> This does not record the size of FW regions, as these aren't bound to a
>> specific open file and remain active through the whole life of the
>> driver.
>>
>> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
>> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
>> ---
[...]
>> diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c b/drivers/gpu/drm/
>> panthor/panthor_mmu.c
>> index c39e3eb1c15d..51f6e66df3f5 100644
>> --- a/drivers/gpu/drm/panthor/panthor_mmu.c
>> +++ b/drivers/gpu/drm/panthor/panthor_mmu.c
>> @@ -1941,6 +1941,41 @@ struct panthor_heap_pool
>> *panthor_vm_get_heap_pool(struct panthor_vm *vm, bool c
>> return pool;
>> }
>> +/**
>> + * panthor_vm_heaps_size() - Calculate size of all heap chunks across
>> all
>> + * heaps over all the heap pools in a VM
>> + * @pfile: File.
>> + * @status: Memory status to be updated.
>> + *
>> + * Calculate all heap chunk sizes in all heap pools bound to a VM. If
>> the VM
>> + * is active, record the size as active as well.
>> + */
>> +void panthor_vm_heaps_sizes(struct panthor_file *pfile, struct
>> drm_memory_stats *status)
>> +{
>> + struct panthor_vm *vm;
>> + unsigned long i;
>> +
>> + if (!pfile->vms)
>> + return;
>> +
>> + xa_for_each(&pfile->vms->xa, i, vm) {
>> + size_t size;
>> +
>> + mutex_lock(&vm->heaps.lock);
>
> Use `scoped_guard` instead?
>
> #include <linux/cleanup.h>
>
> /* ... */
>
> xa_for_each(...) {
> size_t size;
>
> scoped_guard(mutex, &vm->heaps.lock) {
> if (!vm->heaps.pool)
> continue;
>
> size = panthor_heap_pool_size(vm->heaps.pool);
> }
> /* ... */
I don't believe this actually works. The implementation of scoped_guard
uses a for() loop. So the "continue" will be applied to this (hidden)
internal loop rather than the xa_for_each() loop intended.
An alternative would be:
xa_for_each(&pfile->vms->xa, i, vm) {
size_t size = 0;
mutex_lock(&vm->heaps.lock);
if (vm->heaps.pool)
size = panthor_heap_pool_size(vm->heaps.pool);
mutex_unlock(&vm->heaps.lock);
status->resident += size;
status->private += size;
if (vm->as.id >= 0)
status->active += size;
}
(relying on size=0 being a no-op for the additions). Although I was
personally also happy with the original - but perhaps that's just
because I'm old and still feel anxious when I see scoped_guard() ;)
Steve
next prev parent reply other threads:[~2024-12-20 11:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-18 18:18 [PATCH v5 0/2] drm/panthor: Display size of internal kernel BOs through fdinfo Adrián Martínez Larumbe
2024-12-18 18:18 ` [PATCH v5 1/2] drm/panthor: Expose size of driver internal BO's over fdinfo Adrián Martínez Larumbe
2024-12-18 19:14 ` Adrián Larumbe
2024-12-20 11:12 ` Steven Price
2024-12-19 16:30 ` Mihail Atanassov
2024-12-20 11:08 ` Steven Price [this message]
2024-12-20 11:14 ` Mihail Atanassov
2025-01-02 20:35 ` Adrián Martínez Larumbe
2024-12-20 21:06 ` kernel test robot
2024-12-18 18:18 ` [PATCH v5 2/2] Documentation/gpu: Add fdinfo meanings of drm-*-internal memory tags Adrián Martínez Larumbe
2024-12-19 13:06 ` Liviu Dudau
2024-12-20 11:13 ` Steven Price
2025-01-02 21:59 ` Tvrtko Ursulin
2025-01-02 22:18 ` Adrián Martínez Larumbe
2025-01-03 10:49 ` Tvrtko Ursulin
2025-01-06 16:53 ` Adrián Martínez Larumbe
2025-01-07 10:43 ` 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=cf8ea27a-f7de-4518-afb1-61fcf5bbb981@arm.com \
--to=steven.price@arm.com \
--cc=adrian.larumbe@collabora.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mihail.atanassov@arm.com \
--cc=mripard@kernel.org \
--cc=nd@arm.com \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/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
all inboxes | Powered by JetHome®