All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
@ 2022-12-30 22:07 Marek Olšák
  2022-12-30 22:10 ` Marek Olšák
  2023-01-02 15:56 ` Christian König
  0 siblings, 2 replies; 17+ messages in thread
From: Marek Olšák @ 2022-12-30 22:07 UTC (permalink / raw)
  To: amd-gfx mailing list


[-- Attachment #1.1: Type: text/plain, Size: 210 bytes --]

To give userspace a detailed view about its GPU memory usage and evictions.
This will help performance investigations.

Signed-off-by: Marek Olšák <marek.olsak@amd.com>

The patch is attached.

Marek

[-- Attachment #1.2: Type: text/html, Size: 343 bytes --]

[-- Attachment #2: 0002-drm-amdgpu-add-AMDGPU_INFO_VM_STAT-to-return-GPU-VM-.patch --]
[-- Type: text/x-patch, Size: 6598 bytes --]

From 01f41d5b49920b11494ca07f6dde24ea3098fa9f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Ol=C5=A1=C3=A1k?= <marek.olsak@amd.com>
Date: Sat, 24 Dec 2022 17:41:51 -0500
Subject: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
 stats about the process
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

To give userspace a detailed view about its GPU memory usage and evictions.
This will help performance investigations.

Signed-off-by: Marek Olšák <marek.olsak@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 101 ++++++++++++++++++++++++
 include/uapi/drm/amdgpu_drm.h           |  29 +++++++
 3 files changed, 132 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 155f905b00c9..ee1532959032 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -108,9 +108,10 @@
  * - 3.50.0 - Update AMDGPU_INFO_DEV_INFO IOCTL for minimum engine and memory clock
  *            Update AMDGPU_INFO_SENSOR IOCTL for PEAK_PSTATE engine and memory clock
  *   3.51.0 - Return the PCIe gen and lanes from the INFO ioctl
+ *   3.52.0 - Add AMDGPU_INFO_VM_STAT
  */
 #define KMS_DRIVER_MAJOR	3
-#define KMS_DRIVER_MINOR	51
+#define KMS_DRIVER_MINOR	52
 #define KMS_DRIVER_PATCHLEVEL	0
 
 unsigned int amdgpu_vram_limit = UINT_MAX;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index fba306e0ef87..619c3a633ee6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -515,6 +515,67 @@ static int amdgpu_hw_ip_info(struct amdgpu_device *adev,
 	return 0;
 }
 
+static void amdgpu_vm_stat_visit_bo(struct drm_amdgpu_info_vm_stat *stat,
+				    struct amdgpu_bo_va *bo_va)
+{
+	struct amdgpu_bo *bo = bo_va->base.bo;
+	uint64_t size;
+
+	if (!bo)
+		return;
+
+	size = amdgpu_bo_size(bo);
+
+	switch (bo->tbo.resource->mem_type) {
+	case TTM_PL_VRAM:
+		if (bo->tbo.deleted) {
+			stat->unreclaimed_vram += size;
+			stat->unreclaimed_vram_bo_count++;
+		} else {
+			stat->vram += size;
+			stat->vram_bo_count++;
+
+			if (amdgpu_bo_in_cpu_visible_vram(bo)) {
+				stat->visible_vram += size;
+				stat->visible_vram_bo_count++;
+			}
+		}
+		break;
+	case TTM_PL_TT:
+		if (bo->tbo.deleted) {
+			stat->unreclaimed_gtt += size;
+			stat->unreclaimed_gtt_bo_count++;
+		} else {
+			stat->gtt += size;
+			stat->gtt_bo_count++;
+		}
+		break;
+	case TTM_PL_SYSTEM:
+		stat->sysmem += size;
+		stat->sysmem_bo_count++;
+		break;
+	/* Ignore GDS, GWS, and OA - those are not important. */
+	}
+
+	if (bo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM) {
+		stat->requested_vram += size;
+		stat->requested_vram_bo_count++;
+
+		if (bo->tbo.resource->mem_type != TTM_PL_VRAM) {
+			stat->evicted_vram += size;
+			stat->evicted_vram_bo_count++;
+
+			if (bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {
+				stat->evicted_visible_vram += size;
+				stat->evicted_visible_vram_bo_count++;
+			}
+		}
+	} else if (bo->preferred_domains & AMDGPU_GEM_DOMAIN_GTT) {
+		stat->requested_gtt += size;
+		stat->requested_gtt_bo_count++;
+	}
+}
+
 /*
  * Userspace get information ioctl
  */
@@ -1128,6 +1189,46 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file *filp)
 		kfree(caps);
 		return r;
 	}
+	case AMDGPU_INFO_VM_STAT: {
+		struct drm_amdgpu_info_vm_stat stat = {};
+		struct amdgpu_fpriv *fpriv = filp->driver_priv;
+		struct amdgpu_vm *vm = &fpriv->vm;
+		struct amdgpu_bo_va *bo_va, *tmp;
+		int r;
+
+		r = amdgpu_bo_reserve(vm->root.bo, true);
+		if (r)
+			return r;
+
+		spin_lock(&vm->status_lock);
+
+		list_for_each_entry_safe(bo_va, tmp, &vm->idle, base.vm_status) {
+			amdgpu_vm_stat_visit_bo(&stat, bo_va);
+		}
+		list_for_each_entry_safe(bo_va, tmp, &vm->evicted, base.vm_status) {
+			amdgpu_vm_stat_visit_bo(&stat, bo_va);
+		}
+		list_for_each_entry_safe(bo_va, tmp, &vm->relocated, base.vm_status) {
+			amdgpu_vm_stat_visit_bo(&stat, bo_va);
+		}
+		list_for_each_entry_safe(bo_va, tmp, &vm->moved, base.vm_status) {
+			amdgpu_vm_stat_visit_bo(&stat, bo_va);
+		}
+		list_for_each_entry_safe(bo_va, tmp, &vm->invalidated, base.vm_status) {
+			amdgpu_vm_stat_visit_bo(&stat, bo_va);
+		}
+		list_for_each_entry_safe(bo_va, tmp, &vm->done, base.vm_status) {
+			amdgpu_vm_stat_visit_bo(&stat, bo_va);
+		}
+		list_for_each_entry_safe(bo_va, tmp, &vm->freed, base.vm_status) {
+			amdgpu_vm_stat_visit_bo(&stat, bo_va);
+		}
+
+		spin_unlock(&vm->status_lock);
+		amdgpu_bo_unreserve(vm->root.bo);
+		return copy_to_user(out, &stat,
+				    min((size_t)size, sizeof(stat))) ? -EFAULT : 0;
+	}
 	default:
 		DRM_DEBUG_KMS("Invalid request %d\n", info->query);
 		return -EINVAL;
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index f7fc7325f17f..521b7ca0ffe9 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -875,6 +875,7 @@ struct drm_amdgpu_cs_chunk_data {
 	#define AMDGPU_INFO_VIDEO_CAPS_DECODE		0
 	/* Subquery id: Encode */
 	#define AMDGPU_INFO_VIDEO_CAPS_ENCODE		1
+#define AMDGPU_INFO_VM_STAT			0x22
 
 #define AMDGPU_INFO_MMR_SE_INDEX_SHIFT	0
 #define AMDGPU_INFO_MMR_SE_INDEX_MASK	0xff
@@ -1157,6 +1158,34 @@ struct drm_amdgpu_info_vce_clock_table {
 	__u32 pad;
 };
 
+/* Statistics of the current VM - per driver FD. */
+struct drm_amdgpu_info_vm_stat {
+	/* Current memory usage. total = heap + unreclaimed_heap. */
+	__u64		vram;		/* includes visible_vram */
+	__u64		gtt;
+	__u64		sysmem;
+	__u64		unreclaimed_vram; /* marked for freeing */
+	__u64		unreclaimed_gtt;  /* marked for freeing */
+	/* What userspace requested. */
+	__u64		requested_vram;
+	__u64		requested_gtt;
+	/* Other stats. */
+	__u64		visible_vram;	/* included in "vram" */
+	__u64		evicted_vram;	/* VRAM buffers not in VRAM, incl. visible VRAM */
+	__u64		evicted_visible_vram; /* visible VRAM buffers not in VRAM */
+	/* Buffer counts. */
+	__u32           vram_bo_count;
+	__u32           gtt_bo_count;
+	__u32           sysmem_bo_count;
+	__u32           unreclaimed_vram_bo_count;
+	__u32           unreclaimed_gtt_bo_count;
+	__u32		requested_vram_bo_count;
+	__u32		requested_gtt_bo_count;
+	__u32		visible_vram_bo_count;
+	__u32           evicted_vram_bo_count;
+	__u32           evicted_visible_vram_bo_count;
+};
+
 /* query video encode/decode caps */
 #define AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG2			0
 #define AMDGPU_INFO_VIDEO_CAPS_CODEC_IDX_MPEG4			1
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2022-12-30 22:07 [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM Marek Olšák
@ 2022-12-30 22:10 ` Marek Olšák
  2023-01-02 15:56 ` Christian König
  1 sibling, 0 replies; 17+ messages in thread
From: Marek Olšák @ 2022-12-30 22:10 UTC (permalink / raw)
  To: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

FYI, I've fixed the mixed tabs/spaces in amdgpu_drm.h locally.

Marek

On Fri, Dec 30, 2022 at 5:07 PM Marek Olšák <maraeo@gmail.com> wrote:

> To give userspace a detailed view about its GPU memory usage and evictions.
> This will help performance investigations.
>
> Signed-off-by: Marek Olšák <marek.olsak@amd.com>
>
> The patch is attached.
>
> Marek
>

[-- Attachment #2: Type: text/html, Size: 822 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2022-12-30 22:07 [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM Marek Olšák
  2022-12-30 22:10 ` Marek Olšák
@ 2023-01-02 15:56 ` Christian König
  2023-01-02 17:57   ` Marek Olšák
  1 sibling, 1 reply; 17+ messages in thread
From: Christian König @ 2023-01-02 15:56 UTC (permalink / raw)
  To: Marek Olšák, amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

Well first of all don't mess with the VM internals outside of the VM code.

Then why would we want to expose this through the IOCTL interface? We 
already have this in the fdinfo.

Christian.

Am 30.12.22 um 23:07 schrieb Marek Olšák:
> To give userspace a detailed view about its GPU memory usage and 
> evictions.
> This will help performance investigations.
>
> Signed-off-by: Marek Olšák <marek.olsak@amd.com>
>
> The patch is attached.
>
> Marek

[-- Attachment #2: Type: text/html, Size: 1209 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-02 15:56 ` Christian König
@ 2023-01-02 17:57   ` Marek Olšák
  2023-01-03  8:33     ` Christian König
  0 siblings, 1 reply; 17+ messages in thread
From: Marek Olšák @ 2023-01-02 17:57 UTC (permalink / raw)
  To: Christian König; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

What are you talking about? Is fdinfo in sysfs? Userspace drivers can't
access sysfs.

Marek

On Mon, Jan 2, 2023, 10:56 Christian König <ckoenig.leichtzumerken@gmail.com>
wrote:

> Well first of all don't mess with the VM internals outside of the VM code.
>
> Then why would we want to expose this through the IOCTL interface? We
> already have this in the fdinfo.
>
> Christian.
>
> Am 30.12.22 um 23:07 schrieb Marek Olšák:
>
> To give userspace a detailed view about its GPU memory usage and evictions.
> This will help performance investigations.
>
> Signed-off-by: Marek Olšák <marek.olsak@amd.com>
>
> The patch is attached.
>
> Marek
>
>
>

[-- Attachment #2: Type: text/html, Size: 1446 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-02 17:57   ` Marek Olšák
@ 2023-01-03  8:33     ` Christian König
  2023-01-03 23:08       ` Marek Olšák
  0 siblings, 1 reply; 17+ messages in thread
From: Christian König @ 2023-01-03  8:33 UTC (permalink / raw)
  To: Marek Olšák; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

Take a look at /proc/self/fdinfo/$fd.

The Intel guys made that vendor agnostic and are using it within their 
IGT gpu top tool.

Christian.

Am 02.01.23 um 18:57 schrieb Marek Olšák:
> What are you talking about? Is fdinfo in sysfs? Userspace drivers 
> can't access sysfs.
>
> Marek
>
> On Mon, Jan 2, 2023, 10:56 Christian König 
> <ckoenig.leichtzumerken@gmail.com> wrote:
>
>     Well first of all don't mess with the VM internals outside of the
>     VM code.
>
>     Then why would we want to expose this through the IOCTL interface?
>     We already have this in the fdinfo.
>
>     Christian.
>
>     Am 30.12.22 um 23:07 schrieb Marek Olšák:
>>     To give userspace a detailed view about its GPU memory usage and
>>     evictions.
>>     This will help performance investigations.
>>
>>     Signed-off-by: Marek Olšák <marek.olsak@amd.com>
>>
>>     The patch is attached.
>>
>>     Marek
>

[-- Attachment #2: Type: text/html, Size: 2537 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-03  8:33     ` Christian König
@ 2023-01-03 23:08       ` Marek Olšák
  2023-01-04 14:51         ` Christian König
  0 siblings, 1 reply; 17+ messages in thread
From: Marek Olšák @ 2023-01-03 23:08 UTC (permalink / raw)
  To: Christian König; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

I see about the access now, but did you even look at the patch? Because
what the patch does isn't even exposed to common drm code, such as the
preferred domain and visible VRAM placement, so it can't be in fdinfo right
now.

Or do you even know what fdinfo contains? Because it contains nothing
useful. It only has VRAM and GTT usage, which we already have in the INFO
ioctl, so it has nothing that we need. We mainly need the eviction
information and visible VRAM information now. Everything else is a bonus.

Also, it's undesirable to open and parse a text file if we can just call an
ioctl.

So do you want me to move it into amdgpu_vm.c? Because you could have just
said: Let's move it into amdgpu_vm.c. :)

Thanks,
Marek

On Tue, Jan 3, 2023 at 3:33 AM Christian König <
ckoenig.leichtzumerken@gmail.com> wrote:

> Take a look at /proc/self/fdinfo/$fd.
>
> The Intel guys made that vendor agnostic and are using it within their IGT
> gpu top tool.
>
> Christian.
>
> Am 02.01.23 um 18:57 schrieb Marek Olšák:
>
> What are you talking about? Is fdinfo in sysfs? Userspace drivers can't
> access sysfs.
>
> Marek
>
> On Mon, Jan 2, 2023, 10:56 Christian König <
> ckoenig.leichtzumerken@gmail.com> wrote:
>
>> Well first of all don't mess with the VM internals outside of the VM code.
>>
>> Then why would we want to expose this through the IOCTL interface? We
>> already have this in the fdinfo.
>>
>> Christian.
>>
>> Am 30.12.22 um 23:07 schrieb Marek Olšák:
>>
>> To give userspace a detailed view about its GPU memory usage and
>> evictions.
>> This will help performance investigations.
>>
>> Signed-off-by: Marek Olšák <marek.olsak@amd.com>
>>
>> The patch is attached.
>>
>> Marek
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 3469 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-03 23:08       ` Marek Olšák
@ 2023-01-04 14:51         ` Christian König
  2023-01-10 15:28           ` Marek Olšák
  0 siblings, 1 reply; 17+ messages in thread
From: Christian König @ 2023-01-04 14:51 UTC (permalink / raw)
  To: Marek Olšák; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]

Am 04.01.23 um 00:08 schrieb Marek Olšák:
> I see about the access now, but did you even look at the patch?

I did look at the patch, but I haven't fully understood yet what you are 
trying to do here.

> Because what the patch does isn't even exposed to common drm code, 
> such as the preferred domain and visible VRAM placement, so it can't 
> be in fdinfo right now.
>
> Or do you even know what fdinfo contains? Because it contains nothing 
> useful. It only has VRAM and GTT usage, which we already have in the 
> INFO ioctl, so it has nothing that we need. We mainly need the 
> eviction information and visible VRAM information now. Everything else 
> is a bonus.

Well the main question is what are you trying to get from that 
information? The eviction list for example is completely meaningless to 
userspace, that stuff is only temporary and will be cleared on the next 
CS again.

What we could expose is the VRAM over-commit value, e.g. how much BOs 
which where supposed to be in VRAM are in GTT now. I think that's what 
you are looking for here, right?

> Also, it's undesirable to open and parse a text file if we can just 
> call an ioctl.

Well I see the reasoning for that, but I also see why other drivers do a 
lot of the stuff we have as IOCTL as separate files in sysfs, fdinfo or 
debugfs.

Especially repeating all the static information which were already 
available under sysfs in the INFO IOCTL was a design mistake as far as I 
can see. Just compare what AMDGPU and the KFD code is doing to what for 
example i915 is doing.

Same for things like debug information about a process. The fdinfo stuff 
can be queried from external tools (gdb, gputop, umr etc...) as well 
which makes that interface more preferred.

>
> So do you want me to move it into amdgpu_vm.c? Because you could have 
> just said: Let's move it into amdgpu_vm.c. :)
>
> Thanks,
> Marek
>
> On Tue, Jan 3, 2023 at 3:33 AM Christian König 
> <ckoenig.leichtzumerken@gmail.com> wrote:
>
>     Take a look at /proc/self/fdinfo/$fd.
>
>     The Intel guys made that vendor agnostic and are using it within
>     their IGT gpu top tool.
>
>     Christian.
>
>     Am 02.01.23 um 18:57 schrieb Marek Olšák:
>>     What are you talking about? Is fdinfo in sysfs? Userspace drivers
>>     can't access sysfs.
>>
>>     Marek
>>
>>     On Mon, Jan 2, 2023, 10:56 Christian König
>>     <ckoenig.leichtzumerken@gmail.com> wrote:
>>
>>         Well first of all don't mess with the VM internals outside of
>>         the VM code.
>>
>>         Then why would we want to expose this through the IOCTL
>>         interface? We already have this in the fdinfo.
>>
>>         Christian.
>>
>>         Am 30.12.22 um 23:07 schrieb Marek Olšák:
>>>         To give userspace a detailed view about its GPU memory usage
>>>         and evictions.
>>>         This will help performance investigations.
>>>
>>>         Signed-off-by: Marek Olšák <marek.olsak@amd.com>
>>>
>>>         The patch is attached.
>>>
>>>         Marek
>>
>

[-- Attachment #2: Type: text/html, Size: 6718 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-04 14:51         ` Christian König
@ 2023-01-10 15:28           ` Marek Olšák
  2023-01-10 16:23             ` Christian König
  0 siblings, 1 reply; 17+ messages in thread
From: Marek Olšák @ 2023-01-10 15:28 UTC (permalink / raw)
  To: Christian König; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 2752 bytes --]

On Wed, Jan 4, 2023 at 9:51 AM Christian König <
ckoenig.leichtzumerken@gmail.com> wrote:

> Am 04.01.23 um 00:08 schrieb Marek Olšák:
>
> I see about the access now, but did you even look at the patch?
>
>
> I did look at the patch, but I haven't fully understood yet what you are
> trying to do here.
>

First and foremost, it returns the evicted size of VRAM and visible VRAM,
and returns visible VRAM usage. It should be obvious which stat includes
the size of another.


> Because what the patch does isn't even exposed to common drm code, such as
> the preferred domain and visible VRAM placement, so it can't be in fdinfo
> right now.
>
> Or do you even know what fdinfo contains? Because it contains nothing
> useful. It only has VRAM and GTT usage, which we already have in the INFO
> ioctl, so it has nothing that we need. We mainly need the eviction
> information and visible VRAM information now. Everything else is a bonus.
>
>
> Well the main question is what are you trying to get from that
> information? The eviction list for example is completely meaningless to
> userspace, that stuff is only temporary and will be cleared on the next CS
> again.
>

I don't know what you mean. The returned eviction stats look correct and
are stable (they don't change much). You can suggest changes if you think
some numbers are not reported correctly.


>
> What we could expose is the VRAM over-commit value, e.g. how much BOs
> which where supposed to be in VRAM are in GTT now. I think that's what you
> are looking for here, right?
>

The VRAM overcommit value is "evicted_vram".


>
> Also, it's undesirable to open and parse a text file if we can just call
> an ioctl.
>
>
> Well I see the reasoning for that, but I also see why other drivers do a
> lot of the stuff we have as IOCTL as separate files in sysfs, fdinfo or
> debugfs.
>
> Especially repeating all the static information which were already
> available under sysfs in the INFO IOCTL was a design mistake as far as I
> can see. Just compare what AMDGPU and the KFD code is doing to what for
> example i915 is doing.
>
> Same for things like debug information about a process. The fdinfo stuff
> can be queried from external tools (gdb, gputop, umr etc...) as well which
> makes that interface more preferred.
>

Nothing uses fdinfo in Mesa. No driver uses sysfs in Mesa except drm shims,
noop drivers, and Intel for perf metrics. sysfs itself is an unusable mess
for the PCIe query and is missing information.

I'm not against exposing more stuff through sysfs and fdinfo for tools, but
I don't see any reason why drivers should use it (other than for slowing
down queries and initialization).

Marek

[-- Attachment #2: Type: text/html, Size: 4316 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-10 15:28           ` Marek Olšák
@ 2023-01-10 16:23             ` Christian König
  2023-01-10 16:55               ` Marek Olšák
  0 siblings, 1 reply; 17+ messages in thread
From: Christian König @ 2023-01-10 16:23 UTC (permalink / raw)
  To: Marek Olšák; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 4047 bytes --]

Am 10.01.23 um 16:28 schrieb Marek Olšák:
> On Wed, Jan 4, 2023 at 9:51 AM Christian König 
> <ckoenig.leichtzumerken@gmail.com> wrote:
>
>     Am 04.01.23 um 00:08 schrieb Marek Olšák:
>>     I see about the access now, but did you even look at the patch?
>
>     I did look at the patch, but I haven't fully understood yet what
>     you are trying to do here.
>
>
> First and foremost, it returns the evicted size of VRAM and visible 
> VRAM, and returns visible VRAM usage. It should be obvious which stat 
> includes the size of another.
>
>
>>     Because what the patch does isn't even exposed to common drm
>>     code, such as the preferred domain and visible VRAM placement, so
>>     it can't be in fdinfo right now.
>>
>>     Or do you even know what fdinfo contains? Because it contains
>>     nothing useful. It only has VRAM and GTT usage, which we already
>>     have in the INFO ioctl, so it has nothing that we need. We mainly
>>     need the eviction information and visible VRAM information now.
>>     Everything else is a bonus.
>
>     Well the main question is what are you trying to get from that
>     information? The eviction list for example is completely
>     meaningless to userspace, that stuff is only temporary and will be
>     cleared on the next CS again.
>
>
> I don't know what you mean. The returned eviction stats look correct 
> and are stable (they don't change much). You can suggest changes if 
> you think some numbers are not reported correctly.
>
>
>     What we could expose is the VRAM over-commit value, e.g. how much
>     BOs which where supposed to be in VRAM are in GTT now. I think
>     that's what you are looking for here, right?
>
>
> The VRAM overcommit value is "evicted_vram".
>
>
>>     Also, it's undesirable to open and parse a text file if we can
>>     just call an ioctl.
>
>     Well I see the reasoning for that, but I also see why other
>     drivers do a lot of the stuff we have as IOCTL as separate files
>     in sysfs, fdinfo or debugfs.
>
>     Especially repeating all the static information which were already
>     available under sysfs in the INFO IOCTL was a design mistake as
>     far as I can see. Just compare what AMDGPU and the KFD code is
>     doing to what for example i915 is doing.
>
>     Same for things like debug information about a process. The fdinfo
>     stuff can be queried from external tools (gdb, gputop, umr etc...)
>     as well which makes that interface more preferred.
>
>
> Nothing uses fdinfo in Mesa. No driver uses sysfs in Mesa except drm 
> shims, noop drivers, and Intel for perf metrics. sysfs itself is an 
> unusable mess for the PCIe query and is missing information.
>
> I'm not against exposing more stuff through sysfs and fdinfo for 
> tools, but I don't see any reason why drivers should use it (other 
> than for slowing down queries and initialization).

That's what I'm asking: Is this for some tool or to make some driver 
decision based on it?

If you just want the numbers for over displaying then I think it would 
be better to put this into fdinfo together with the other existing stuff 
there.

If you want to make allocation decisions based on this then we should 
have that as IOCTL or even better as mmap() page between kernel and 
userspace. But in this case I would also calculation the numbers 
completely different as well.

See we have at least the following things in the kernel:
1. The eviction list in the VM.
     Those are the BOs which are currently evicted and tried to moved 
back in on the next CS.

2. The VRAM over commit value.
     In other words how much more VRAM than available has the 
application tried to allocate?

3. The visible VRAM usage by this application.

The end goal is that the eviction list will go away, e.g. we will always 
have stable allocations based on allocations of other applications and 
not constantly swap things in and out.

When you now expose the eviction list to userspace we will be stuck with 
this interface forever.

Christian.

>
> Marek

[-- Attachment #2: Type: text/html, Size: 7578 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-10 16:23             ` Christian König
@ 2023-01-10 16:55               ` Marek Olšák
  2023-01-21  0:45                 ` Marek Olšák
  0 siblings, 1 reply; 17+ messages in thread
From: Marek Olšák @ 2023-01-10 16:55 UTC (permalink / raw)
  To: Christian König; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 4883 bytes --]

On Tue, Jan 10, 2023 at 11:23 AM Christian König <
ckoenig.leichtzumerken@gmail.com> wrote:

> Am 10.01.23 um 16:28 schrieb Marek Olšák:
>
> On Wed, Jan 4, 2023 at 9:51 AM Christian König <
> ckoenig.leichtzumerken@gmail.com> wrote:
>
>> Am 04.01.23 um 00:08 schrieb Marek Olšák:
>>
>> I see about the access now, but did you even look at the patch?
>>
>>
>> I did look at the patch, but I haven't fully understood yet what you are
>> trying to do here.
>>
>
> First and foremost, it returns the evicted size of VRAM and visible VRAM,
> and returns visible VRAM usage. It should be obvious which stat includes
> the size of another.
>
>
>> Because what the patch does isn't even exposed to common drm code, such
>> as the preferred domain and visible VRAM placement, so it can't be in
>> fdinfo right now.
>>
>> Or do you even know what fdinfo contains? Because it contains nothing
>> useful. It only has VRAM and GTT usage, which we already have in the INFO
>> ioctl, so it has nothing that we need. We mainly need the eviction
>> information and visible VRAM information now. Everything else is a bonus.
>>
>>
>> Well the main question is what are you trying to get from that
>> information? The eviction list for example is completely meaningless to
>> userspace, that stuff is only temporary and will be cleared on the next CS
>> again.
>>
>
> I don't know what you mean. The returned eviction stats look correct and
> are stable (they don't change much). You can suggest changes if you think
> some numbers are not reported correctly.
>
>
>>
>> What we could expose is the VRAM over-commit value, e.g. how much BOs
>> which where supposed to be in VRAM are in GTT now. I think that's what you
>> are looking for here, right?
>>
>
> The VRAM overcommit value is "evicted_vram".
>
>
>>
>> Also, it's undesirable to open and parse a text file if we can just call
>> an ioctl.
>>
>>
>> Well I see the reasoning for that, but I also see why other drivers do a
>> lot of the stuff we have as IOCTL as separate files in sysfs, fdinfo or
>> debugfs.
>>
>> Especially repeating all the static information which were already
>> available under sysfs in the INFO IOCTL was a design mistake as far as I
>> can see. Just compare what AMDGPU and the KFD code is doing to what for
>> example i915 is doing.
>>
>> Same for things like debug information about a process. The fdinfo stuff
>> can be queried from external tools (gdb, gputop, umr etc...) as well which
>> makes that interface more preferred.
>>
>
> Nothing uses fdinfo in Mesa. No driver uses sysfs in Mesa except drm
> shims, noop drivers, and Intel for perf metrics. sysfs itself is an
> unusable mess for the PCIe query and is missing information.
>
> I'm not against exposing more stuff through sysfs and fdinfo for tools,
> but I don't see any reason why drivers should use it (other than for
> slowing down queries and initialization).
>
>
> That's what I'm asking: Is this for some tool or to make some driver
> decision based on it?
>
> If you just want the numbers for over displaying then I think it would be
> better to put this into fdinfo together with the other existing stuff there.
>

> If you want to make allocation decisions based on this then we should have
> that as IOCTL or even better as mmap() page between kernel and userspace.
> But in this case I would also calculation the numbers completely different
> as well.
>
> See we have at least the following things in the kernel:
> 1. The eviction list in the VM.
>     Those are the BOs which are currently evicted and tried to moved back
> in on the next CS.
>
> 2. The VRAM over commit value.
>     In other words how much more VRAM than available has the application
> tried to allocate?
>
> 3. The visible VRAM usage by this application.
>
> The end goal is that the eviction list will go away, e.g. we will always
> have stable allocations based on allocations of other applications and not
> constantly swap things in and out.
>
> When you now expose the eviction list to userspace we will be stuck with
> this interface forever.
>

It's for the GALLIUM HUD.

The only missing thing is the size of all evicted VRAM allocations, and the
size of all evicted visible VRAM allocations.

1. No list is exposed. Only sums of buffer sizes are exposed. Also, the
eviction list has no meaning here. All lists are treated equally, and
mem_type is compared with preferred_domains to determine where buffers are
and where they should be.

2. I'm not interested in the overcommit value. I'm only interested in
knowing the number of bytes of evicted VRAM right now. It can be as
variable as the CPU load, but in practice it shouldn't be because PCIe
doesn't have the bandwidth to move things quickly.

3. Yes, that's true.

Marek

[-- Attachment #2: Type: text/html, Size: 8456 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-10 16:55               ` Marek Olšák
@ 2023-01-21  0:45                 ` Marek Olšák
  2023-01-23  9:31                   ` Christian König
  0 siblings, 1 reply; 17+ messages in thread
From: Marek Olšák @ 2023-01-21  0:45 UTC (permalink / raw)
  To: Christian König; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 5368 bytes --]

We badly need a way to query evicted memory usage. It's essential for
investigating performance problems and it uncovered the buddy allocator
disaster. Please either suggest an alternative, suggest changes, or review.
We need it ASAP.

Thanks,
Marek

On Tue, Jan 10, 2023 at 11:55 AM Marek Olšák <maraeo@gmail.com> wrote:

> On Tue, Jan 10, 2023 at 11:23 AM Christian König <
> ckoenig.leichtzumerken@gmail.com> wrote:
>
>> Am 10.01.23 um 16:28 schrieb Marek Olšák:
>>
>> On Wed, Jan 4, 2023 at 9:51 AM Christian König <
>> ckoenig.leichtzumerken@gmail.com> wrote:
>>
>>> Am 04.01.23 um 00:08 schrieb Marek Olšák:
>>>
>>> I see about the access now, but did you even look at the patch?
>>>
>>>
>>> I did look at the patch, but I haven't fully understood yet what you are
>>> trying to do here.
>>>
>>
>> First and foremost, it returns the evicted size of VRAM and visible VRAM,
>> and returns visible VRAM usage. It should be obvious which stat includes
>> the size of another.
>>
>>
>>> Because what the patch does isn't even exposed to common drm code, such
>>> as the preferred domain and visible VRAM placement, so it can't be in
>>> fdinfo right now.
>>>
>>> Or do you even know what fdinfo contains? Because it contains nothing
>>> useful. It only has VRAM and GTT usage, which we already have in the INFO
>>> ioctl, so it has nothing that we need. We mainly need the eviction
>>> information and visible VRAM information now. Everything else is a bonus.
>>>
>>>
>>> Well the main question is what are you trying to get from that
>>> information? The eviction list for example is completely meaningless to
>>> userspace, that stuff is only temporary and will be cleared on the next CS
>>> again.
>>>
>>
>> I don't know what you mean. The returned eviction stats look correct and
>> are stable (they don't change much). You can suggest changes if you think
>> some numbers are not reported correctly.
>>
>>
>>>
>>> What we could expose is the VRAM over-commit value, e.g. how much BOs
>>> which where supposed to be in VRAM are in GTT now. I think that's what you
>>> are looking for here, right?
>>>
>>
>> The VRAM overcommit value is "evicted_vram".
>>
>>
>>>
>>> Also, it's undesirable to open and parse a text file if we can just call
>>> an ioctl.
>>>
>>>
>>> Well I see the reasoning for that, but I also see why other drivers do a
>>> lot of the stuff we have as IOCTL as separate files in sysfs, fdinfo or
>>> debugfs.
>>>
>>> Especially repeating all the static information which were already
>>> available under sysfs in the INFO IOCTL was a design mistake as far as I
>>> can see. Just compare what AMDGPU and the KFD code is doing to what for
>>> example i915 is doing.
>>>
>>> Same for things like debug information about a process. The fdinfo stuff
>>> can be queried from external tools (gdb, gputop, umr etc...) as well which
>>> makes that interface more preferred.
>>>
>>
>> Nothing uses fdinfo in Mesa. No driver uses sysfs in Mesa except drm
>> shims, noop drivers, and Intel for perf metrics. sysfs itself is an
>> unusable mess for the PCIe query and is missing information.
>>
>> I'm not against exposing more stuff through sysfs and fdinfo for tools,
>> but I don't see any reason why drivers should use it (other than for
>> slowing down queries and initialization).
>>
>>
>> That's what I'm asking: Is this for some tool or to make some driver
>> decision based on it?
>>
>> If you just want the numbers for over displaying then I think it would be
>> better to put this into fdinfo together with the other existing stuff there.
>>
>
>> If you want to make allocation decisions based on this then we should
>> have that as IOCTL or even better as mmap() page between kernel and
>> userspace. But in this case I would also calculation the numbers completely
>> different as well.
>>
>> See we have at least the following things in the kernel:
>> 1. The eviction list in the VM.
>>     Those are the BOs which are currently evicted and tried to moved back
>> in on the next CS.
>>
>> 2. The VRAM over commit value.
>>     In other words how much more VRAM than available has the application
>> tried to allocate?
>>
>> 3. The visible VRAM usage by this application.
>>
>> The end goal is that the eviction list will go away, e.g. we will always
>> have stable allocations based on allocations of other applications and not
>> constantly swap things in and out.
>>
>> When you now expose the eviction list to userspace we will be stuck with
>> this interface forever.
>>
>
> It's for the GALLIUM HUD.
>
> The only missing thing is the size of all evicted VRAM allocations, and
> the size of all evicted visible VRAM allocations.
>
> 1. No list is exposed. Only sums of buffer sizes are exposed. Also, the
> eviction list has no meaning here. All lists are treated equally, and
> mem_type is compared with preferred_domains to determine where buffers are
> and where they should be.
>
> 2. I'm not interested in the overcommit value. I'm only interested in
> knowing the number of bytes of evicted VRAM right now. It can be as
> variable as the CPU load, but in practice it shouldn't be because PCIe
> doesn't have the bandwidth to move things quickly.
>
> 3. Yes, that's true.
>
> Marek
>
>

[-- Attachment #2: Type: text/html, Size: 9146 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-21  0:45                 ` Marek Olšák
@ 2023-01-23  9:31                   ` Christian König
  2023-01-24  7:37                     ` Marek Olšák
  0 siblings, 1 reply; 17+ messages in thread
From: Christian König @ 2023-01-23  9:31 UTC (permalink / raw)
  To: Marek Olšák; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 6190 bytes --]

Let's do this as valid in fdinfo.

This way we can easily extend whatever the kernel wants to display as 
statistics in the userspace HUD.

Regards,
Christian.

Am 21.01.23 um 01:45 schrieb Marek Olšák:
> We badly need a way to query evicted memory usage. It's essential for 
> investigating performance problems and it uncovered the buddy 
> allocator disaster. Please either suggest an alternative, suggest 
> changes, or review. We need it ASAP.
>
> Thanks,
> Marek
>
> On Tue, Jan 10, 2023 at 11:55 AM Marek Olšák <maraeo@gmail.com> wrote:
>
>     On Tue, Jan 10, 2023 at 11:23 AM Christian König
>     <ckoenig.leichtzumerken@gmail.com> wrote:
>
>         Am 10.01.23 um 16:28 schrieb Marek Olšák:
>>         On Wed, Jan 4, 2023 at 9:51 AM Christian König
>>         <ckoenig.leichtzumerken@gmail.com> wrote:
>>
>>             Am 04.01.23 um 00:08 schrieb Marek Olšák:
>>>             I see about the access now, but did you even look at the
>>>             patch?
>>
>>             I did look at the patch, but I haven't fully understood
>>             yet what you are trying to do here.
>>
>>
>>         First and foremost, it returns the evicted size of VRAM and
>>         visible VRAM, and returns visible VRAM usage. It should be
>>         obvious which stat includes the size of another.
>>
>>
>>>             Because what the patch does isn't even exposed to common
>>>             drm code, such as the preferred domain and visible VRAM
>>>             placement, so it can't be in fdinfo right now.
>>>
>>>             Or do you even know what fdinfo contains? Because it
>>>             contains nothing useful. It only has VRAM and GTT usage,
>>>             which we already have in the INFO ioctl, so it has
>>>             nothing that we need. We mainly need the eviction
>>>             information and visible VRAM information now. Everything
>>>             else is a bonus.
>>
>>             Well the main question is what are you trying to get from
>>             that information? The eviction list for example is
>>             completely meaningless to userspace, that stuff is only
>>             temporary and will be cleared on the next CS again.
>>
>>
>>         I don't know what you mean. The returned eviction stats look
>>         correct and are stable (they don't change much). You can
>>         suggest changes if you think some numbers are not reported
>>         correctly.
>>
>>
>>             What we could expose is the VRAM over-commit value, e.g.
>>             how much BOs which where supposed to be in VRAM are in
>>             GTT now. I think that's what you are looking for here, right?
>>
>>
>>         The VRAM overcommit value is "evicted_vram".
>>
>>
>>>             Also, it's undesirable to open and parse a text file if
>>>             we can just call an ioctl.
>>
>>             Well I see the reasoning for that, but I also see why
>>             other drivers do a lot of the stuff we have as IOCTL as
>>             separate files in sysfs, fdinfo or debugfs.
>>
>>             Especially repeating all the static information which
>>             were already available under sysfs in the INFO IOCTL was
>>             a design mistake as far as I can see. Just compare what
>>             AMDGPU and the KFD code is doing to what for example i915
>>             is doing.
>>
>>             Same for things like debug information about a process.
>>             The fdinfo stuff can be queried from external tools (gdb,
>>             gputop, umr etc...) as well which makes that interface
>>             more preferred.
>>
>>
>>         Nothing uses fdinfo in Mesa. No driver uses sysfs in Mesa
>>         except drm shims, noop drivers, and Intel for perf metrics.
>>         sysfs itself is an unusable mess for the PCIe query and is
>>         missing information.
>>
>>         I'm not against exposing more stuff through sysfs and fdinfo
>>         for tools, but I don't see any reason why drivers should use
>>         it (other than for slowing down queries and initialization).
>
>         That's what I'm asking: Is this for some tool or to make some
>         driver decision based on it?
>
>         If you just want the numbers for over displaying then I think
>         it would be better to put this into fdinfo together with the
>         other existing stuff there.
>
>
>         If you want to make allocation decisions based on this then we
>         should have that as IOCTL or even better as mmap() page
>         between kernel and userspace. But in this case I would also
>         calculation the numbers completely different as well.
>
>         See we have at least the following things in the kernel:
>         1. The eviction list in the VM.
>             Those are the BOs which are currently evicted and tried to
>         moved back in on the next CS.
>
>         2. The VRAM over commit value.
>             In other words how much more VRAM than available has the
>         application tried to allocate?
>
>         3. The visible VRAM usage by this application.
>
>         The end goal is that the eviction list will go away, e.g. we
>         will always have stable allocations based on allocations of
>         other applications and not constantly swap things in and out.
>
>         When you now expose the eviction list to userspace we will be
>         stuck with this interface forever.
>
>
>     It's for the GALLIUM HUD.
>
>     The only missing thing is the size of all evicted VRAM
>     allocations, and the size of all evicted visible VRAM allocations.
>
>     1. No list is exposed. Only sums of buffer sizes are exposed.
>     Also, the eviction list has no meaning here. All lists are treated
>     equally, and mem_type is compared with preferred_domains to
>     determine where buffers are and where they should be.
>
>     2. I'm not interested in the overcommit value. I'm only interested
>     in knowing the number of bytes of evicted VRAM right now. It can
>     be as variable as the CPU load, but in practice it shouldn't be
>     because PCIe doesn't have the bandwidth to move things quickly.
>
>     3. Yes, that's true.
>
>     Marek
>

[-- Attachment #2: Type: text/html, Size: 13800 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-23  9:31                   ` Christian König
@ 2023-01-24  7:37                     ` Marek Olšák
  2023-01-24  7:58                       ` Christian König
  0 siblings, 1 reply; 17+ messages in thread
From: Marek Olšák @ 2023-01-24  7:37 UTC (permalink / raw)
  To: Christian König; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 6202 bytes --]

The Gallium HUD doesn't consume strings. It only consumes values that are
exposed as counters from the driver. In this case, we need the driver to
expose evicted stats as counters. Each counter can set whether the value is
absolute (e.g. memory usage) or monotonic (e.g. perf counter). Parsing
fdinfo to get the values is undesirable.

Marek

On Mon, Jan 23, 2023 at 4:31 AM Christian König <
ckoenig.leichtzumerken@gmail.com> wrote:

> Let's do this as valid in fdinfo.
>
> This way we can easily extend whatever the kernel wants to display as
> statistics in the userspace HUD.
>
> Regards,
> Christian.
>
> Am 21.01.23 um 01:45 schrieb Marek Olšák:
>
> We badly need a way to query evicted memory usage. It's essential for
> investigating performance problems and it uncovered the buddy allocator
> disaster. Please either suggest an alternative, suggest changes, or review.
> We need it ASAP.
>
> Thanks,
> Marek
>
> On Tue, Jan 10, 2023 at 11:55 AM Marek Olšák <maraeo@gmail.com> wrote:
>
>> On Tue, Jan 10, 2023 at 11:23 AM Christian König <
>> ckoenig.leichtzumerken@gmail.com> wrote:
>>
>>> Am 10.01.23 um 16:28 schrieb Marek Olšák:
>>>
>>> On Wed, Jan 4, 2023 at 9:51 AM Christian König <
>>> ckoenig.leichtzumerken@gmail.com> wrote:
>>>
>>>> Am 04.01.23 um 00:08 schrieb Marek Olšák:
>>>>
>>>> I see about the access now, but did you even look at the patch?
>>>>
>>>>
>>>> I did look at the patch, but I haven't fully understood yet what you
>>>> are trying to do here.
>>>>
>>>
>>> First and foremost, it returns the evicted size of VRAM and visible
>>> VRAM, and returns visible VRAM usage. It should be obvious which stat
>>> includes the size of another.
>>>
>>>
>>>> Because what the patch does isn't even exposed to common drm code, such
>>>> as the preferred domain and visible VRAM placement, so it can't be in
>>>> fdinfo right now.
>>>>
>>>> Or do you even know what fdinfo contains? Because it contains nothing
>>>> useful. It only has VRAM and GTT usage, which we already have in the INFO
>>>> ioctl, so it has nothing that we need. We mainly need the eviction
>>>> information and visible VRAM information now. Everything else is a bonus.
>>>>
>>>>
>>>> Well the main question is what are you trying to get from that
>>>> information? The eviction list for example is completely meaningless to
>>>> userspace, that stuff is only temporary and will be cleared on the next CS
>>>> again.
>>>>
>>>
>>> I don't know what you mean. The returned eviction stats look correct and
>>> are stable (they don't change much). You can suggest changes if you think
>>> some numbers are not reported correctly.
>>>
>>>
>>>>
>>>> What we could expose is the VRAM over-commit value, e.g. how much BOs
>>>> which where supposed to be in VRAM are in GTT now. I think that's what you
>>>> are looking for here, right?
>>>>
>>>
>>> The VRAM overcommit value is "evicted_vram".
>>>
>>>
>>>>
>>>> Also, it's undesirable to open and parse a text file if we can just
>>>> call an ioctl.
>>>>
>>>>
>>>> Well I see the reasoning for that, but I also see why other drivers do
>>>> a lot of the stuff we have as IOCTL as separate files in sysfs, fdinfo or
>>>> debugfs.
>>>>
>>>> Especially repeating all the static information which were already
>>>> available under sysfs in the INFO IOCTL was a design mistake as far as I
>>>> can see. Just compare what AMDGPU and the KFD code is doing to what for
>>>> example i915 is doing.
>>>>
>>>> Same for things like debug information about a process. The fdinfo
>>>> stuff can be queried from external tools (gdb, gputop, umr etc...) as well
>>>> which makes that interface more preferred.
>>>>
>>>
>>> Nothing uses fdinfo in Mesa. No driver uses sysfs in Mesa except drm
>>> shims, noop drivers, and Intel for perf metrics. sysfs itself is an
>>> unusable mess for the PCIe query and is missing information.
>>>
>>> I'm not against exposing more stuff through sysfs and fdinfo for tools,
>>> but I don't see any reason why drivers should use it (other than for
>>> slowing down queries and initialization).
>>>
>>>
>>> That's what I'm asking: Is this for some tool or to make some driver
>>> decision based on it?
>>>
>>> If you just want the numbers for over displaying then I think it would
>>> be better to put this into fdinfo together with the other existing stuff
>>> there.
>>>
>>
>>> If you want to make allocation decisions based on this then we should
>>> have that as IOCTL or even better as mmap() page between kernel and
>>> userspace. But in this case I would also calculation the numbers completely
>>> different as well.
>>>
>>> See we have at least the following things in the kernel:
>>> 1. The eviction list in the VM.
>>>     Those are the BOs which are currently evicted and tried to moved
>>> back in on the next CS.
>>>
>>> 2. The VRAM over commit value.
>>>     In other words how much more VRAM than available has the application
>>> tried to allocate?
>>>
>>> 3. The visible VRAM usage by this application.
>>>
>>> The end goal is that the eviction list will go away, e.g. we will always
>>> have stable allocations based on allocations of other applications and not
>>> constantly swap things in and out.
>>>
>>> When you now expose the eviction list to userspace we will be stuck with
>>> this interface forever.
>>>
>>
>> It's for the GALLIUM HUD.
>>
>> The only missing thing is the size of all evicted VRAM allocations, and
>> the size of all evicted visible VRAM allocations.
>>
>> 1. No list is exposed. Only sums of buffer sizes are exposed. Also, the
>> eviction list has no meaning here. All lists are treated equally, and
>> mem_type is compared with preferred_domains to determine where buffers are
>> and where they should be.
>>
>> 2. I'm not interested in the overcommit value. I'm only interested in
>> knowing the number of bytes of evicted VRAM right now. It can be as
>> variable as the CPU load, but in practice it shouldn't be because PCIe
>> doesn't have the bandwidth to move things quickly.
>>
>> 3. Yes, that's true.
>>
>> Marek
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 13948 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-24  7:37                     ` Marek Olšák
@ 2023-01-24  7:58                       ` Christian König
  2023-01-24  8:13                         ` Marek Olšák
  0 siblings, 1 reply; 17+ messages in thread
From: Christian König @ 2023-01-24  7:58 UTC (permalink / raw)
  To: Marek Olšák; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 7943 bytes --]

How are the counters which the HUD consumes declared?

See what I want to avoid is a) to nail down the interface with the 
kernel on specific values and b) make it possible to easily expose new 
values.

In other words what we could do with fdinfo is to have something like this:

GALLIUM_FDINFO_HUD=drm-memory-vram,amd-evicted-vram,amd-mclk glxgears

And the HUD just displays the values the kernel provides without the 
need to re-compile mesa when we want to add some more values nor have 
the values as part of the UAPI.

Christian.

Am 24.01.23 um 08:37 schrieb Marek Olšák:
> The Gallium HUD doesn't consume strings. It only consumes values that 
> are exposed as counters from the driver. In this case, we need the 
> driver to expose evicted stats as counters. Each counter can set 
> whether the value is absolute (e.g. memory usage) or monotonic (e.g. 
> perf counter). Parsing fdinfo to get the values is undesirable.
>
> Marek
>
> On Mon, Jan 23, 2023 at 4:31 AM Christian König 
> <ckoenig.leichtzumerken@gmail.com> wrote:
>
>     Let's do this as valid in fdinfo.
>
>     This way we can easily extend whatever the kernel wants to display
>     as statistics in the userspace HUD.
>
>     Regards,
>     Christian.
>
>     Am 21.01.23 um 01:45 schrieb Marek Olšák:
>>     We badly need a way to query evicted memory usage. It's essential
>>     for investigating performance problems and it uncovered the buddy
>>     allocator disaster. Please either suggest an alternative, suggest
>>     changes, or review. We need it ASAP.
>>
>>     Thanks,
>>     Marek
>>
>>     On Tue, Jan 10, 2023 at 11:55 AM Marek Olšák <maraeo@gmail.com>
>>     wrote:
>>
>>         On Tue, Jan 10, 2023 at 11:23 AM Christian König
>>         <ckoenig.leichtzumerken@gmail.com> wrote:
>>
>>             Am 10.01.23 um 16:28 schrieb Marek Olšák:
>>>             On Wed, Jan 4, 2023 at 9:51 AM Christian König
>>>             <ckoenig.leichtzumerken@gmail.com> wrote:
>>>
>>>                 Am 04.01.23 um 00:08 schrieb Marek Olšák:
>>>>                 I see about the access now, but did you even look
>>>>                 at the patch?
>>>
>>>                 I did look at the patch, but I haven't fully
>>>                 understood yet what you are trying to do here.
>>>
>>>
>>>             First and foremost, it returns the evicted size of VRAM
>>>             and visible VRAM, and returns visible VRAM usage. It
>>>             should be obvious which stat includes the size of another.
>>>
>>>
>>>>                 Because what the patch does isn't even exposed to
>>>>                 common drm code, such as the preferred domain and
>>>>                 visible VRAM placement, so it can't be in fdinfo
>>>>                 right now.
>>>>
>>>>                 Or do you even know what fdinfo contains? Because
>>>>                 it contains nothing useful. It only has VRAM and
>>>>                 GTT usage, which we already have in the INFO ioctl,
>>>>                 so it has nothing that we need. We mainly need the
>>>>                 eviction information and visible VRAM information
>>>>                 now. Everything else is a bonus.
>>>
>>>                 Well the main question is what are you trying to get
>>>                 from that information? The eviction list for example
>>>                 is completely meaningless to userspace, that stuff
>>>                 is only temporary and will be cleared on the next CS
>>>                 again.
>>>
>>>
>>>             I don't know what you mean. The returned eviction stats
>>>             look correct and are stable (they don't change much).
>>>             You can suggest changes if you think some numbers are
>>>             not reported correctly.
>>>
>>>
>>>                 What we could expose is the VRAM over-commit value,
>>>                 e.g. how much BOs which where supposed to be in VRAM
>>>                 are in GTT now. I think that's what you are looking
>>>                 for here, right?
>>>
>>>
>>>             The VRAM overcommit value is "evicted_vram".
>>>
>>>
>>>>                 Also, it's undesirable to open and parse a text
>>>>                 file if we can just call an ioctl.
>>>
>>>                 Well I see the reasoning for that, but I also see
>>>                 why other drivers do a lot of the stuff we have as
>>>                 IOCTL as separate files in sysfs, fdinfo or debugfs.
>>>
>>>                 Especially repeating all the static information
>>>                 which were already available under sysfs in the INFO
>>>                 IOCTL was a design mistake as far as I can see. Just
>>>                 compare what AMDGPU and the KFD code is doing to
>>>                 what for example i915 is doing.
>>>
>>>                 Same for things like debug information about a
>>>                 process. The fdinfo stuff can be queried from
>>>                 external tools (gdb, gputop, umr etc...) as well
>>>                 which makes that interface more preferred.
>>>
>>>
>>>             Nothing uses fdinfo in Mesa. No driver uses sysfs in
>>>             Mesa except drm shims, noop drivers, and Intel for perf
>>>             metrics. sysfs itself is an unusable mess for the PCIe
>>>             query and is missing information.
>>>
>>>             I'm not against exposing more stuff through sysfs and
>>>             fdinfo for tools, but I don't see any reason why drivers
>>>             should use it (other than for slowing down queries and
>>>             initialization).
>>
>>             That's what I'm asking: Is this for some tool or to make
>>             some driver decision based on it?
>>
>>             If you just want the numbers for over displaying then I
>>             think it would be better to put this into fdinfo together
>>             with the other existing stuff there.
>>
>>
>>             If you want to make allocation decisions based on this
>>             then we should have that as IOCTL or even better as
>>             mmap() page between kernel and userspace. But in this
>>             case I would also calculation the numbers completely
>>             different as well.
>>
>>             See we have at least the following things in the kernel:
>>             1. The eviction list in the VM.
>>                 Those are the BOs which are currently evicted and
>>             tried to moved back in on the next CS.
>>
>>             2. The VRAM over commit value.
>>                 In other words how much more VRAM than available has
>>             the application tried to allocate?
>>
>>             3. The visible VRAM usage by this application.
>>
>>             The end goal is that the eviction list will go away, e.g.
>>             we will always have stable allocations based on
>>             allocations of other applications and not constantly swap
>>             things in and out.
>>
>>             When you now expose the eviction list to userspace we
>>             will be stuck with this interface forever.
>>
>>
>>         It's for the GALLIUM HUD.
>>
>>         The only missing thing is the size of all evicted VRAM
>>         allocations, and the size of all evicted visible VRAM
>>         allocations.
>>
>>         1. No list is exposed. Only sums of buffer sizes are exposed.
>>         Also, the eviction list has no meaning here. All lists are
>>         treated equally, and mem_type is compared with
>>         preferred_domains to determine where buffers are and where
>>         they should be.
>>
>>         2. I'm not interested in the overcommit value. I'm only
>>         interested in knowing the number of bytes of evicted VRAM
>>         right now. It can be as variable as the CPU load, but in
>>         practice it shouldn't be because PCIe doesn't have the
>>         bandwidth to move things quickly.
>>
>>         3. Yes, that's true.
>>
>>         Marek
>>
>

[-- Attachment #2: Type: text/html, Size: 18575 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-24  7:58                       ` Christian König
@ 2023-01-24  8:13                         ` Marek Olšák
  2023-01-24  8:27                           ` Marek Olšák
  0 siblings, 1 reply; 17+ messages in thread
From: Marek Olšák @ 2023-01-24  8:13 UTC (permalink / raw)
  To: Christian König; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 7706 bytes --]

The table of exposed driver-specific counters:
https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/radeonsi/si_query.c#L1751

Counter enums. They use the same interface as e.g. occlusion queries,
except that begin_query and end_query save the results in the driver/CPU.
https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/radeonsi/si_query.h#L45

Counters exposed by the winsys:
https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/include/winsys/radeon_winsys.h#L126

I just need to query the counters in the winsys and return them.

Marek

On Tue, Jan 24, 2023 at 2:58 AM Christian König <
ckoenig.leichtzumerken@gmail.com> wrote:

> How are the counters which the HUD consumes declared?
>
> See what I want to avoid is a) to nail down the interface with the kernel
> on specific values and b) make it possible to easily expose new values.
>
> In other words what we could do with fdinfo is to have something like this:
>
> GALLIUM_FDINFO_HUD=drm-memory-vram,amd-evicted-vram,amd-mclk glxgears
>
> And the HUD just displays the values the kernel provides without the need
> to re-compile mesa when we want to add some more values nor have the values
> as part of the UAPI.
>
> Christian.
>
> Am 24.01.23 um 08:37 schrieb Marek Olšák:
>
> The Gallium HUD doesn't consume strings. It only consumes values that are
> exposed as counters from the driver. In this case, we need the driver to
> expose evicted stats as counters. Each counter can set whether the value is
> absolute (e.g. memory usage) or monotonic (e.g. perf counter). Parsing
> fdinfo to get the values is undesirable.
>
> Marek
>
> On Mon, Jan 23, 2023 at 4:31 AM Christian König <
> ckoenig.leichtzumerken@gmail.com> wrote:
>
>> Let's do this as valid in fdinfo.
>>
>> This way we can easily extend whatever the kernel wants to display as
>> statistics in the userspace HUD.
>>
>> Regards,
>> Christian.
>>
>> Am 21.01.23 um 01:45 schrieb Marek Olšák:
>>
>> We badly need a way to query evicted memory usage. It's essential for
>> investigating performance problems and it uncovered the buddy allocator
>> disaster. Please either suggest an alternative, suggest changes, or review.
>> We need it ASAP.
>>
>> Thanks,
>> Marek
>>
>> On Tue, Jan 10, 2023 at 11:55 AM Marek Olšák <maraeo@gmail.com> wrote:
>>
>>> On Tue, Jan 10, 2023 at 11:23 AM Christian König <
>>> ckoenig.leichtzumerken@gmail.com> wrote:
>>>
>>>> Am 10.01.23 um 16:28 schrieb Marek Olšák:
>>>>
>>>> On Wed, Jan 4, 2023 at 9:51 AM Christian König <
>>>> ckoenig.leichtzumerken@gmail.com> wrote:
>>>>
>>>>> Am 04.01.23 um 00:08 schrieb Marek Olšák:
>>>>>
>>>>> I see about the access now, but did you even look at the patch?
>>>>>
>>>>>
>>>>> I did look at the patch, but I haven't fully understood yet what you
>>>>> are trying to do here.
>>>>>
>>>>
>>>> First and foremost, it returns the evicted size of VRAM and visible
>>>> VRAM, and returns visible VRAM usage. It should be obvious which stat
>>>> includes the size of another.
>>>>
>>>>
>>>>> Because what the patch does isn't even exposed to common drm code,
>>>>> such as the preferred domain and visible VRAM placement, so it can't be in
>>>>> fdinfo right now.
>>>>>
>>>>> Or do you even know what fdinfo contains? Because it contains nothing
>>>>> useful. It only has VRAM and GTT usage, which we already have in the INFO
>>>>> ioctl, so it has nothing that we need. We mainly need the eviction
>>>>> information and visible VRAM information now. Everything else is a bonus.
>>>>>
>>>>>
>>>>> Well the main question is what are you trying to get from that
>>>>> information? The eviction list for example is completely meaningless to
>>>>> userspace, that stuff is only temporary and will be cleared on the next CS
>>>>> again.
>>>>>
>>>>
>>>> I don't know what you mean. The returned eviction stats look correct
>>>> and are stable (they don't change much). You can suggest changes if you
>>>> think some numbers are not reported correctly.
>>>>
>>>>
>>>>>
>>>>> What we could expose is the VRAM over-commit value, e.g. how much BOs
>>>>> which where supposed to be in VRAM are in GTT now. I think that's what you
>>>>> are looking for here, right?
>>>>>
>>>>
>>>> The VRAM overcommit value is "evicted_vram".
>>>>
>>>>
>>>>>
>>>>> Also, it's undesirable to open and parse a text file if we can just
>>>>> call an ioctl.
>>>>>
>>>>>
>>>>> Well I see the reasoning for that, but I also see why other drivers do
>>>>> a lot of the stuff we have as IOCTL as separate files in sysfs, fdinfo or
>>>>> debugfs.
>>>>>
>>>>> Especially repeating all the static information which were already
>>>>> available under sysfs in the INFO IOCTL was a design mistake as far as I
>>>>> can see. Just compare what AMDGPU and the KFD code is doing to what for
>>>>> example i915 is doing.
>>>>>
>>>>> Same for things like debug information about a process. The fdinfo
>>>>> stuff can be queried from external tools (gdb, gputop, umr etc...) as well
>>>>> which makes that interface more preferred.
>>>>>
>>>>
>>>> Nothing uses fdinfo in Mesa. No driver uses sysfs in Mesa except drm
>>>> shims, noop drivers, and Intel for perf metrics. sysfs itself is an
>>>> unusable mess for the PCIe query and is missing information.
>>>>
>>>> I'm not against exposing more stuff through sysfs and fdinfo for tools,
>>>> but I don't see any reason why drivers should use it (other than for
>>>> slowing down queries and initialization).
>>>>
>>>>
>>>> That's what I'm asking: Is this for some tool or to make some driver
>>>> decision based on it?
>>>>
>>>> If you just want the numbers for over displaying then I think it would
>>>> be better to put this into fdinfo together with the other existing stuff
>>>> there.
>>>>
>>>
>>>> If you want to make allocation decisions based on this then we should
>>>> have that as IOCTL or even better as mmap() page between kernel and
>>>> userspace. But in this case I would also calculation the numbers completely
>>>> different as well.
>>>>
>>>> See we have at least the following things in the kernel:
>>>> 1. The eviction list in the VM.
>>>>     Those are the BOs which are currently evicted and tried to moved
>>>> back in on the next CS.
>>>>
>>>> 2. The VRAM over commit value.
>>>>     In other words how much more VRAM than available has the
>>>> application tried to allocate?
>>>>
>>>> 3. The visible VRAM usage by this application.
>>>>
>>>> The end goal is that the eviction list will go away, e.g. we will
>>>> always have stable allocations based on allocations of other applications
>>>> and not constantly swap things in and out.
>>>>
>>>> When you now expose the eviction list to userspace we will be stuck
>>>> with this interface forever.
>>>>
>>>
>>> It's for the GALLIUM HUD.
>>>
>>> The only missing thing is the size of all evicted VRAM allocations, and
>>> the size of all evicted visible VRAM allocations.
>>>
>>> 1. No list is exposed. Only sums of buffer sizes are exposed. Also, the
>>> eviction list has no meaning here. All lists are treated equally, and
>>> mem_type is compared with preferred_domains to determine where buffers are
>>> and where they should be.
>>>
>>> 2. I'm not interested in the overcommit value. I'm only interested in
>>> knowing the number of bytes of evicted VRAM right now. It can be as
>>> variable as the CPU load, but in practice it shouldn't be because PCIe
>>> doesn't have the bandwidth to move things quickly.
>>>
>>> 3. Yes, that's true.
>>>
>>> Marek
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 19178 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-24  8:13                         ` Marek Olšák
@ 2023-01-24  8:27                           ` Marek Olšák
  2023-01-24  8:29                             ` Christian König
  0 siblings, 1 reply; 17+ messages in thread
From: Marek Olšák @ 2023-01-24  8:27 UTC (permalink / raw)
  To: Christian König; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 8179 bytes --]

A new Gallium HUD "value producer" could be added that reads fdinfo without
calling the driver. I still think there is merit in having this in
amdgpu_drm.h too.

Marek

On Tue, Jan 24, 2023 at 3:13 AM Marek Olšák <maraeo@gmail.com> wrote:

> The table of exposed driver-specific counters:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/radeonsi/si_query.c#L1751
>
> Counter enums. They use the same interface as e.g. occlusion queries,
> except that begin_query and end_query save the results in the driver/CPU.
>
> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/radeonsi/si_query.h#L45
>
> Counters exposed by the winsys:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/include/winsys/radeon_winsys.h#L126
>
> I just need to query the counters in the winsys and return them.
>
> Marek
>
> On Tue, Jan 24, 2023 at 2:58 AM Christian König <
> ckoenig.leichtzumerken@gmail.com> wrote:
>
>> How are the counters which the HUD consumes declared?
>>
>> See what I want to avoid is a) to nail down the interface with the kernel
>> on specific values and b) make it possible to easily expose new values.
>>
>> In other words what we could do with fdinfo is to have something like
>> this:
>>
>> GALLIUM_FDINFO_HUD=drm-memory-vram,amd-evicted-vram,amd-mclk glxgears
>>
>> And the HUD just displays the values the kernel provides without the need
>> to re-compile mesa when we want to add some more values nor have the values
>> as part of the UAPI.
>>
>> Christian.
>>
>> Am 24.01.23 um 08:37 schrieb Marek Olšák:
>>
>> The Gallium HUD doesn't consume strings. It only consumes values that are
>> exposed as counters from the driver. In this case, we need the driver to
>> expose evicted stats as counters. Each counter can set whether the value is
>> absolute (e.g. memory usage) or monotonic (e.g. perf counter). Parsing
>> fdinfo to get the values is undesirable.
>>
>> Marek
>>
>> On Mon, Jan 23, 2023 at 4:31 AM Christian König <
>> ckoenig.leichtzumerken@gmail.com> wrote:
>>
>>> Let's do this as valid in fdinfo.
>>>
>>> This way we can easily extend whatever the kernel wants to display as
>>> statistics in the userspace HUD.
>>>
>>> Regards,
>>> Christian.
>>>
>>> Am 21.01.23 um 01:45 schrieb Marek Olšák:
>>>
>>> We badly need a way to query evicted memory usage. It's essential for
>>> investigating performance problems and it uncovered the buddy allocator
>>> disaster. Please either suggest an alternative, suggest changes, or review.
>>> We need it ASAP.
>>>
>>> Thanks,
>>> Marek
>>>
>>> On Tue, Jan 10, 2023 at 11:55 AM Marek Olšák <maraeo@gmail.com> wrote:
>>>
>>>> On Tue, Jan 10, 2023 at 11:23 AM Christian König <
>>>> ckoenig.leichtzumerken@gmail.com> wrote:
>>>>
>>>>> Am 10.01.23 um 16:28 schrieb Marek Olšák:
>>>>>
>>>>> On Wed, Jan 4, 2023 at 9:51 AM Christian König <
>>>>> ckoenig.leichtzumerken@gmail.com> wrote:
>>>>>
>>>>>> Am 04.01.23 um 00:08 schrieb Marek Olšák:
>>>>>>
>>>>>> I see about the access now, but did you even look at the patch?
>>>>>>
>>>>>>
>>>>>> I did look at the patch, but I haven't fully understood yet what you
>>>>>> are trying to do here.
>>>>>>
>>>>>
>>>>> First and foremost, it returns the evicted size of VRAM and visible
>>>>> VRAM, and returns visible VRAM usage. It should be obvious which stat
>>>>> includes the size of another.
>>>>>
>>>>>
>>>>>> Because what the patch does isn't even exposed to common drm code,
>>>>>> such as the preferred domain and visible VRAM placement, so it can't be in
>>>>>> fdinfo right now.
>>>>>>
>>>>>> Or do you even know what fdinfo contains? Because it contains nothing
>>>>>> useful. It only has VRAM and GTT usage, which we already have in the INFO
>>>>>> ioctl, so it has nothing that we need. We mainly need the eviction
>>>>>> information and visible VRAM information now. Everything else is a bonus.
>>>>>>
>>>>>>
>>>>>> Well the main question is what are you trying to get from that
>>>>>> information? The eviction list for example is completely meaningless to
>>>>>> userspace, that stuff is only temporary and will be cleared on the next CS
>>>>>> again.
>>>>>>
>>>>>
>>>>> I don't know what you mean. The returned eviction stats look correct
>>>>> and are stable (they don't change much). You can suggest changes if you
>>>>> think some numbers are not reported correctly.
>>>>>
>>>>>
>>>>>>
>>>>>> What we could expose is the VRAM over-commit value, e.g. how much BOs
>>>>>> which where supposed to be in VRAM are in GTT now. I think that's what you
>>>>>> are looking for here, right?
>>>>>>
>>>>>
>>>>> The VRAM overcommit value is "evicted_vram".
>>>>>
>>>>>
>>>>>>
>>>>>> Also, it's undesirable to open and parse a text file if we can just
>>>>>> call an ioctl.
>>>>>>
>>>>>>
>>>>>> Well I see the reasoning for that, but I also see why other drivers
>>>>>> do a lot of the stuff we have as IOCTL as separate files in sysfs, fdinfo
>>>>>> or debugfs.
>>>>>>
>>>>>> Especially repeating all the static information which were already
>>>>>> available under sysfs in the INFO IOCTL was a design mistake as far as I
>>>>>> can see. Just compare what AMDGPU and the KFD code is doing to what for
>>>>>> example i915 is doing.
>>>>>>
>>>>>> Same for things like debug information about a process. The fdinfo
>>>>>> stuff can be queried from external tools (gdb, gputop, umr etc...) as well
>>>>>> which makes that interface more preferred.
>>>>>>
>>>>>
>>>>> Nothing uses fdinfo in Mesa. No driver uses sysfs in Mesa except drm
>>>>> shims, noop drivers, and Intel for perf metrics. sysfs itself is an
>>>>> unusable mess for the PCIe query and is missing information.
>>>>>
>>>>> I'm not against exposing more stuff through sysfs and fdinfo for
>>>>> tools, but I don't see any reason why drivers should use it (other than for
>>>>> slowing down queries and initialization).
>>>>>
>>>>>
>>>>> That's what I'm asking: Is this for some tool or to make some driver
>>>>> decision based on it?
>>>>>
>>>>> If you just want the numbers for over displaying then I think it would
>>>>> be better to put this into fdinfo together with the other existing stuff
>>>>> there.
>>>>>
>>>>
>>>>> If you want to make allocation decisions based on this then we should
>>>>> have that as IOCTL or even better as mmap() page between kernel and
>>>>> userspace. But in this case I would also calculation the numbers completely
>>>>> different as well.
>>>>>
>>>>> See we have at least the following things in the kernel:
>>>>> 1. The eviction list in the VM.
>>>>>     Those are the BOs which are currently evicted and tried to moved
>>>>> back in on the next CS.
>>>>>
>>>>> 2. The VRAM over commit value.
>>>>>     In other words how much more VRAM than available has the
>>>>> application tried to allocate?
>>>>>
>>>>> 3. The visible VRAM usage by this application.
>>>>>
>>>>> The end goal is that the eviction list will go away, e.g. we will
>>>>> always have stable allocations based on allocations of other applications
>>>>> and not constantly swap things in and out.
>>>>>
>>>>> When you now expose the eviction list to userspace we will be stuck
>>>>> with this interface forever.
>>>>>
>>>>
>>>> It's for the GALLIUM HUD.
>>>>
>>>> The only missing thing is the size of all evicted VRAM allocations, and
>>>> the size of all evicted visible VRAM allocations.
>>>>
>>>> 1. No list is exposed. Only sums of buffer sizes are exposed. Also, the
>>>> eviction list has no meaning here. All lists are treated equally, and
>>>> mem_type is compared with preferred_domains to determine where buffers are
>>>> and where they should be.
>>>>
>>>> 2. I'm not interested in the overcommit value. I'm only interested in
>>>> knowing the number of bytes of evicted VRAM right now. It can be as
>>>> variable as the CPU load, but in practice it shouldn't be because PCIe
>>>> doesn't have the bandwidth to move things quickly.
>>>>
>>>> 3. Yes, that's true.
>>>>
>>>> Marek
>>>>
>>>>
>>>
>>

[-- Attachment #2: Type: text/html, Size: 19825 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM
  2023-01-24  8:27                           ` Marek Olšák
@ 2023-01-24  8:29                             ` Christian König
  0 siblings, 0 replies; 17+ messages in thread
From: Christian König @ 2023-01-24  8:29 UTC (permalink / raw)
  To: Marek Olšák; +Cc: amd-gfx mailing list

[-- Attachment #1: Type: text/plain, Size: 10768 bytes --]

Am 24.01.23 um 09:27 schrieb Marek Olšák:
> A new Gallium HUD "value producer" could be added that reads fdinfo 
> without calling the driver.

That sounds good. To be honest I would have plenty of use for that.

> I still think there is merit in having this in amdgpu_drm.h too.

Why?

Christian.

>
> Marek
>
> On Tue, Jan 24, 2023 at 3:13 AM Marek Olšák <maraeo@gmail.com> wrote:
>
>     The table of exposed driver-specific counters:
>     https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/radeonsi/si_query.c#L1751
>
>     Counter enums. They use the same interface as e.g. occlusion
>     queries, except that begin_query and end_query save the results in
>     the driver/CPU.
>     https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/radeonsi/si_query.h#L45
>
>     Counters exposed by the winsys:
>     https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/include/winsys/radeon_winsys.h#L126
>
>     I just need to query the counters in the winsys and return them.
>
>     Marek
>
>     On Tue, Jan 24, 2023 at 2:58 AM Christian König
>     <ckoenig.leichtzumerken@gmail.com> wrote:
>
>         How are the counters which the HUD consumes declared?
>
>         See what I want to avoid is a) to nail down the interface with
>         the kernel on specific values and b) make it possible to
>         easily expose new values.
>
>         In other words what we could do with fdinfo is to have
>         something like this:
>
>         GALLIUM_FDINFO_HUD=drm-memory-vram,amd-evicted-vram,amd-mclk
>         glxgears
>
>         And the HUD just displays the values the kernel provides
>         without the need to re-compile mesa when we want to add some
>         more values nor have the values as part of the UAPI.
>
>         Christian.
>
>         Am 24.01.23 um 08:37 schrieb Marek Olšák:
>>         The Gallium HUD doesn't consume strings. It only consumes
>>         values that are exposed as counters from the driver. In this
>>         case, we need the driver to expose evicted stats as counters.
>>         Each counter can set whether the value is absolute (e.g.
>>         memory usage) or monotonic (e.g. perf counter). Parsing
>>         fdinfo to get the values is undesirable.
>>
>>         Marek
>>
>>         On Mon, Jan 23, 2023 at 4:31 AM Christian König
>>         <ckoenig.leichtzumerken@gmail.com> wrote:
>>
>>             Let's do this as valid in fdinfo.
>>
>>             This way we can easily extend whatever the kernel wants
>>             to display as statistics in the userspace HUD.
>>
>>             Regards,
>>             Christian.
>>
>>             Am 21.01.23 um 01:45 schrieb Marek Olšák:
>>>             We badly need a way to query evicted memory usage. It's
>>>             essential for investigating performance problems and it
>>>             uncovered the buddy allocator disaster. Please either
>>>             suggest an alternative, suggest changes, or review. We
>>>             need it ASAP.
>>>
>>>             Thanks,
>>>             Marek
>>>
>>>             On Tue, Jan 10, 2023 at 11:55 AM Marek Olšák
>>>             <maraeo@gmail.com> wrote:
>>>
>>>                 On Tue, Jan 10, 2023 at 11:23 AM Christian König
>>>                 <ckoenig.leichtzumerken@gmail.com> wrote:
>>>
>>>                     Am 10.01.23 um 16:28 schrieb Marek Olšák:
>>>>                     On Wed, Jan 4, 2023 at 9:51 AM Christian König
>>>>                     <ckoenig.leichtzumerken@gmail.com> wrote:
>>>>
>>>>                         Am 04.01.23 um 00:08 schrieb Marek Olšák:
>>>>>                         I see about the access now, but did you
>>>>>                         even look at the patch?
>>>>
>>>>                         I did look at the patch, but I haven't
>>>>                         fully understood yet what you are trying to
>>>>                         do here.
>>>>
>>>>
>>>>                     First and foremost, it returns the evicted size
>>>>                     of VRAM and visible VRAM, and returns visible
>>>>                     VRAM usage. It should be obvious which stat
>>>>                     includes the size of another.
>>>>
>>>>
>>>>>                         Because what the patch does isn't even
>>>>>                         exposed to common drm code, such as the
>>>>>                         preferred domain and visible VRAM
>>>>>                         placement, so it can't be in fdinfo right now.
>>>>>
>>>>>                         Or do you even know what fdinfo contains?
>>>>>                         Because it contains nothing useful. It
>>>>>                         only has VRAM and GTT usage, which we
>>>>>                         already have in the INFO ioctl, so it has
>>>>>                         nothing that we need. We mainly need the
>>>>>                         eviction information and visible VRAM
>>>>>                         information now. Everything else is a bonus.
>>>>
>>>>                         Well the main question is what are you
>>>>                         trying to get from that information? The
>>>>                         eviction list for example is completely
>>>>                         meaningless to userspace, that stuff is
>>>>                         only temporary and will be cleared on the
>>>>                         next CS again.
>>>>
>>>>
>>>>                     I don't know what you mean. The returned
>>>>                     eviction stats look correct and are stable
>>>>                     (they don't change much). You can suggest
>>>>                     changes if you think some numbers are not
>>>>                     reported correctly.
>>>>
>>>>
>>>>                         What we could expose is the VRAM
>>>>                         over-commit value, e.g. how much BOs which
>>>>                         where supposed to be in VRAM are in GTT
>>>>                         now. I think that's what you are looking
>>>>                         for here, right?
>>>>
>>>>
>>>>                     The VRAM overcommit value is "evicted_vram".
>>>>
>>>>
>>>>>                         Also, it's undesirable to open and parse a
>>>>>                         text file if we can just call an ioctl.
>>>>
>>>>                         Well I see the reasoning for that, but I
>>>>                         also see why other drivers do a lot of the
>>>>                         stuff we have as IOCTL as separate files in
>>>>                         sysfs, fdinfo or debugfs.
>>>>
>>>>                         Especially repeating all the static
>>>>                         information which were already available
>>>>                         under sysfs in the INFO IOCTL was a design
>>>>                         mistake as far as I can see. Just compare
>>>>                         what AMDGPU and the KFD code is doing to
>>>>                         what for example i915 is doing.
>>>>
>>>>                         Same for things like debug information
>>>>                         about a process. The fdinfo stuff can be
>>>>                         queried from external tools (gdb, gputop,
>>>>                         umr etc...) as well which makes that
>>>>                         interface more preferred.
>>>>
>>>>
>>>>                     Nothing uses fdinfo in Mesa. No driver uses
>>>>                     sysfs in Mesa except drm shims, noop drivers,
>>>>                     and Intel for perf metrics. sysfs itself is an
>>>>                     unusable mess for the PCIe query and is missing
>>>>                     information.
>>>>
>>>>                     I'm not against exposing more stuff through
>>>>                     sysfs and fdinfo for tools, but I don't see any
>>>>                     reason why drivers should use it (other than
>>>>                     for slowing down queries and initialization).
>>>
>>>                     That's what I'm asking: Is this for some tool or
>>>                     to make some driver decision based on it?
>>>
>>>                     If you just want the numbers for over displaying
>>>                     then I think it would be better to put this into
>>>                     fdinfo together with the other existing stuff there.
>>>
>>>
>>>                     If you want to make allocation decisions based
>>>                     on this then we should have that as IOCTL or
>>>                     even better as mmap() page between kernel and
>>>                     userspace. But in this case I would also
>>>                     calculation the numbers completely different as
>>>                     well.
>>>
>>>                     See we have at least the following things in the
>>>                     kernel:
>>>                     1. The eviction list in the VM.
>>>                         Those are the BOs which are currently
>>>                     evicted and tried to moved back in on the next CS.
>>>
>>>                     2. The VRAM over commit value.
>>>                         In other words how much more VRAM than
>>>                     available has the application tried to allocate?
>>>
>>>                     3. The visible VRAM usage by this application.
>>>
>>>                     The end goal is that the eviction list will go
>>>                     away, e.g. we will always have stable
>>>                     allocations based on allocations of other
>>>                     applications and not constantly swap things in
>>>                     and out.
>>>
>>>                     When you now expose the eviction list to
>>>                     userspace we will be stuck with this interface
>>>                     forever.
>>>
>>>
>>>                 It's for the GALLIUM HUD.
>>>
>>>                 The only missing thing is the size of all evicted
>>>                 VRAM allocations, and the size of all evicted
>>>                 visible VRAM allocations.
>>>
>>>                 1. No list is exposed. Only sums of buffer sizes are
>>>                 exposed. Also, the eviction list has no meaning
>>>                 here. All lists are treated equally, and mem_type is
>>>                 compared with preferred_domains to determine where
>>>                 buffers are and where they should be.
>>>
>>>                 2. I'm not interested in the overcommit value. I'm
>>>                 only interested in knowing the number of bytes of
>>>                 evicted VRAM right now. It can be as variable as the
>>>                 CPU load, but in practice it shouldn't be because
>>>                 PCIe doesn't have the bandwidth to move things quickly.
>>>
>>>                 3. Yes, that's true.
>>>
>>>                 Marek
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 29829 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2023-01-24  8:29 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-30 22:07 [PATCH 2/2] drm/amdgpu: add AMDGPU_INFO_VM_STAT to return GPU VM Marek Olšák
2022-12-30 22:10 ` Marek Olšák
2023-01-02 15:56 ` Christian König
2023-01-02 17:57   ` Marek Olšák
2023-01-03  8:33     ` Christian König
2023-01-03 23:08       ` Marek Olšák
2023-01-04 14:51         ` Christian König
2023-01-10 15:28           ` Marek Olšák
2023-01-10 16:23             ` Christian König
2023-01-10 16:55               ` Marek Olšák
2023-01-21  0:45                 ` Marek Olšák
2023-01-23  9:31                   ` Christian König
2023-01-24  7:37                     ` Marek Olšák
2023-01-24  7:58                       ` Christian König
2023-01-24  8:13                         ` Marek Olšák
2023-01-24  8:27                           ` Marek Olšák
2023-01-24  8:29                             ` Christian König

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.