mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®