All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nieto, David M" <David.Nieto@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	"Koenig, Christian" <Christian.Koenig@amd.com>,
	"jhubbard@nvidia.com" <jhubbard@nvidia.com>,
	"aritger@nvidia.com" <aritger@nvidia.com>
Cc: Alex Deucher <alexdeucher@gmail.com>,
	"nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
	Intel Graphics Development <Intel-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [Nouveau] [PATCH 0/7] Per client engine busyness
Date: Mon, 17 May 2021 18:16:58 +0000	[thread overview]
Message-ID: <BYAPR12MB284090FAC1C6E149F0A1A0ECF42D9@BYAPR12MB2840.namprd12.prod.outlook.com> (raw)
In-Reply-To: <BYAPR12MB28409E25DEFD3DD620E596ABF42D9@BYAPR12MB2840.namprd12.prod.outlook.com>


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

[Public]

Cycling some of the Nvidia/nouveau guys here too.

I think there is a benefit on trying to estandarize how fdinfo can be used to expose per engine and device memory utilization.

Another of the advantages of going the /proc/ way instead of the sysfs debugfs approach is that you inherit the access lists directly from the distribution and you don't need to start messing with ownership and group access. By default an user can monitor its own processes as long as /proc is mounted.

I am not saying that fdinfo or the way we implemented is 100% the way to go, but I'd rather have a solution within the confines of proc first.

David



________________________________
From: Nieto, David M <David.Nieto@amd.com>
Sent: Monday, May 17, 2021 11:02 AM
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>; Daniel Vetter <daniel@ffwll.ch>; Koenig, Christian <Christian.Koenig@amd.com>
Cc: Alex Deucher <alexdeucher@gmail.com>; Intel Graphics Development <Intel-gfx@lists.freedesktop.org>; Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/7] Per client engine busyness

The format is simple:

<ringname><index>: <XXX.XX> %

we also have entries for the memory mapped:
mem <ttm pool> : <size> KiB

On my submission https://lists.freedesktop.org/archives/amd-gfx/2021-May/063149.html I added a python script to print out the info. It has a CPU usage lower that top, for example.

To be absolutely honest, I agree that there is an overhead, but It might not be as much as you fear.
________________________________
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Sent: Monday, May 17, 2021 9:00 AM
To: Nieto, David M <David.Nieto@amd.com>; Daniel Vetter <daniel@ffwll.ch>; Koenig, Christian <Christian.Koenig@amd.com>
Cc: Alex Deucher <alexdeucher@gmail.com>; Intel Graphics Development <Intel-gfx@lists.freedesktop.org>; Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/7] Per client engine busyness


On 17/05/2021 15:39, Nieto, David M wrote:
> [AMD Official Use Only]
>
>
> Maybe we could try to standardize how the different submission ring
>   usage gets exposed in the fdinfo? We went the simple way of just
> adding name and index, but if someone has a suggestion on how else we
> could format them so there is commonality across vendors we could just
> amend those.

Could you paste an example of your format?

Standardized fdinfo sounds good to me in principle. But I would also
like people to look at the procfs proposal from Chris,
  - link to which I have pasted elsewhere in the thread.

Only potential issue with fdinfo I see at the moment is a bit of an
extra cost in DRM client discovery (compared to my sysfs series and also
procfs RFC from Chris). It would require reading all processes (well
threads, then maybe aggregating threads into parent processes), all fd
symlinks, and doing a stat on them to figure out which ones are DRM devices.

Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers.

> I’d really like to have the process managers tools display GPU usage
> regardless of what vendor is installed.

Definitely.

Regards,

Tvrtko

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

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

WARNING: multiple messages have this Message-ID (diff)
From: "Nieto, David M" <David.Nieto@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	"Koenig, Christian" <Christian.Koenig@amd.com>,
	"jhubbard@nvidia.com" <jhubbard@nvidia.com>,
	"aritger@nvidia.com" <aritger@nvidia.com>
Cc: "nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
	Intel Graphics Development <Intel-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/7] Per client engine busyness
Date: Mon, 17 May 2021 18:16:58 +0000	[thread overview]
Message-ID: <BYAPR12MB284090FAC1C6E149F0A1A0ECF42D9@BYAPR12MB2840.namprd12.prod.outlook.com> (raw)
In-Reply-To: <BYAPR12MB28409E25DEFD3DD620E596ABF42D9@BYAPR12MB2840.namprd12.prod.outlook.com>

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

[Public]

Cycling some of the Nvidia/nouveau guys here too.

I think there is a benefit on trying to estandarize how fdinfo can be used to expose per engine and device memory utilization.

Another of the advantages of going the /proc/ way instead of the sysfs debugfs approach is that you inherit the access lists directly from the distribution and you don't need to start messing with ownership and group access. By default an user can monitor its own processes as long as /proc is mounted.

I am not saying that fdinfo or the way we implemented is 100% the way to go, but I'd rather have a solution within the confines of proc first.

David



________________________________
From: Nieto, David M <David.Nieto@amd.com>
Sent: Monday, May 17, 2021 11:02 AM
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>; Daniel Vetter <daniel@ffwll.ch>; Koenig, Christian <Christian.Koenig@amd.com>
Cc: Alex Deucher <alexdeucher@gmail.com>; Intel Graphics Development <Intel-gfx@lists.freedesktop.org>; Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/7] Per client engine busyness

The format is simple:

<ringname><index>: <XXX.XX> %

we also have entries for the memory mapped:
mem <ttm pool> : <size> KiB

On my submission https://lists.freedesktop.org/archives/amd-gfx/2021-May/063149.html I added a python script to print out the info. It has a CPU usage lower that top, for example.

To be absolutely honest, I agree that there is an overhead, but It might not be as much as you fear.
________________________________
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Sent: Monday, May 17, 2021 9:00 AM
To: Nieto, David M <David.Nieto@amd.com>; Daniel Vetter <daniel@ffwll.ch>; Koenig, Christian <Christian.Koenig@amd.com>
Cc: Alex Deucher <alexdeucher@gmail.com>; Intel Graphics Development <Intel-gfx@lists.freedesktop.org>; Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/7] Per client engine busyness


On 17/05/2021 15:39, Nieto, David M wrote:
> [AMD Official Use Only]
>
>
> Maybe we could try to standardize how the different submission ring
>   usage gets exposed in the fdinfo? We went the simple way of just
> adding name and index, but if someone has a suggestion on how else we
> could format them so there is commonality across vendors we could just
> amend those.

Could you paste an example of your format?

Standardized fdinfo sounds good to me in principle. But I would also
like people to look at the procfs proposal from Chris,
  - link to which I have pasted elsewhere in the thread.

Only potential issue with fdinfo I see at the moment is a bit of an
extra cost in DRM client discovery (compared to my sysfs series and also
procfs RFC from Chris). It would require reading all processes (well
threads, then maybe aggregating threads into parent processes), all fd
symlinks, and doing a stat on them to figure out which ones are DRM devices.

Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers.

> I’d really like to have the process managers tools display GPU usage
> regardless of what vendor is installed.

Definitely.

Regards,

Tvrtko

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

WARNING: multiple messages have this Message-ID (diff)
From: "Nieto, David M" <David.Nieto@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	"Koenig, Christian" <Christian.Koenig@amd.com>,
	"jhubbard@nvidia.com" <jhubbard@nvidia.com>,
	"aritger@nvidia.com" <aritger@nvidia.com>
Cc: Alex Deucher <alexdeucher@gmail.com>,
	"nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
	Intel Graphics Development <Intel-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness
Date: Mon, 17 May 2021 18:16:58 +0000	[thread overview]
Message-ID: <BYAPR12MB284090FAC1C6E149F0A1A0ECF42D9@BYAPR12MB2840.namprd12.prod.outlook.com> (raw)
In-Reply-To: <BYAPR12MB28409E25DEFD3DD620E596ABF42D9@BYAPR12MB2840.namprd12.prod.outlook.com>


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

[Public]

Cycling some of the Nvidia/nouveau guys here too.

I think there is a benefit on trying to estandarize how fdinfo can be used to expose per engine and device memory utilization.

Another of the advantages of going the /proc/ way instead of the sysfs debugfs approach is that you inherit the access lists directly from the distribution and you don't need to start messing with ownership and group access. By default an user can monitor its own processes as long as /proc is mounted.

I am not saying that fdinfo or the way we implemented is 100% the way to go, but I'd rather have a solution within the confines of proc first.

David



________________________________
From: Nieto, David M <David.Nieto@amd.com>
Sent: Monday, May 17, 2021 11:02 AM
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>; Daniel Vetter <daniel@ffwll.ch>; Koenig, Christian <Christian.Koenig@amd.com>
Cc: Alex Deucher <alexdeucher@gmail.com>; Intel Graphics Development <Intel-gfx@lists.freedesktop.org>; Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/7] Per client engine busyness

The format is simple:

<ringname><index>: <XXX.XX> %

we also have entries for the memory mapped:
mem <ttm pool> : <size> KiB

On my submission https://lists.freedesktop.org/archives/amd-gfx/2021-May/063149.html I added a python script to print out the info. It has a CPU usage lower that top, for example.

To be absolutely honest, I agree that there is an overhead, but It might not be as much as you fear.
________________________________
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Sent: Monday, May 17, 2021 9:00 AM
To: Nieto, David M <David.Nieto@amd.com>; Daniel Vetter <daniel@ffwll.ch>; Koenig, Christian <Christian.Koenig@amd.com>
Cc: Alex Deucher <alexdeucher@gmail.com>; Intel Graphics Development <Intel-gfx@lists.freedesktop.org>; Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 0/7] Per client engine busyness


On 17/05/2021 15:39, Nieto, David M wrote:
> [AMD Official Use Only]
>
>
> Maybe we could try to standardize how the different submission ring
>   usage gets exposed in the fdinfo? We went the simple way of just
> adding name and index, but if someone has a suggestion on how else we
> could format them so there is commonality across vendors we could just
> amend those.

Could you paste an example of your format?

Standardized fdinfo sounds good to me in principle. But I would also
like people to look at the procfs proposal from Chris,
  - link to which I have pasted elsewhere in the thread.

Only potential issue with fdinfo I see at the moment is a bit of an
extra cost in DRM client discovery (compared to my sysfs series and also
procfs RFC from Chris). It would require reading all processes (well
threads, then maybe aggregating threads into parent processes), all fd
symlinks, and doing a stat on them to figure out which ones are DRM devices.

Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers.

> I’d really like to have the process managers tools display GPU usage
> regardless of what vendor is installed.

Definitely.

Regards,

Tvrtko

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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-05-17 22:22 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-13 10:59 [PATCH 0/7] Per client engine busyness Tvrtko Ursulin
2021-05-13 10:59 ` [Intel-gfx] " Tvrtko Ursulin
2021-05-13 10:59 ` [PATCH 1/7] drm/i915: Expose list of clients in sysfs Tvrtko Ursulin
2021-05-13 10:59   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-13 10:59 ` [PATCH 2/7] drm/i915: Update client name on context create Tvrtko Ursulin
2021-05-13 10:59   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-13 10:59 ` [PATCH 3/7] drm/i915: Make GEM contexts track DRM clients Tvrtko Ursulin
2021-05-13 10:59   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-13 10:59 ` [PATCH 4/7] drm/i915: Track runtime spent in closed and unreachable GEM contexts Tvrtko Ursulin
2021-05-13 10:59   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-13 11:00 ` [PATCH 5/7] drm/i915: Track all user contexts per client Tvrtko Ursulin
2021-05-13 11:00   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-13 11:00 ` [PATCH 6/7] drm/i915: Track context current active time Tvrtko Ursulin
2021-05-13 11:00   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-13 11:00 ` [PATCH 7/7] drm/i915: Expose per-engine client busyness Tvrtko Ursulin
2021-05-13 11:00   ` [Intel-gfx] " Tvrtko Ursulin
2021-05-13 11:28 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per client engine busyness Patchwork
2021-05-13 11:30 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-05-13 11:59 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-05-13 15:48 ` [PATCH 0/7] " Alex Deucher
2021-05-13 15:48   ` [Intel-gfx] " Alex Deucher
2021-05-13 16:40   ` Tvrtko Ursulin
2021-05-13 16:40     ` [Intel-gfx] " Tvrtko Ursulin
2021-05-14  5:58     ` Alex Deucher
2021-05-14  5:58       ` [Intel-gfx] " Alex Deucher
2021-05-14  7:22       ` Nieto, David M
2021-05-14  7:22         ` [Intel-gfx] " Nieto, David M
2021-05-14  8:04         ` Christian König
2021-05-14  8:04           ` [Intel-gfx] " Christian König
2021-05-14 13:42           ` Tvrtko Ursulin
2021-05-14 13:42             ` [Intel-gfx] " Tvrtko Ursulin
2021-05-14 13:53             ` Christian König
2021-05-14 13:53               ` [Intel-gfx] " Christian König
2021-05-14 14:47               ` Tvrtko Ursulin
2021-05-14 14:47                 ` [Intel-gfx] " Tvrtko Ursulin
2021-05-14 14:56                 ` Christian König
2021-05-14 14:56                   ` [Intel-gfx] " Christian König
2021-05-14 15:03                   ` Tvrtko Ursulin
2021-05-14 15:03                     ` [Intel-gfx] " Tvrtko Ursulin
2021-05-14 15:10                     ` Christian König
2021-05-14 15:10                       ` [Intel-gfx] " Christian König
2021-05-17 14:30                       ` Daniel Vetter
2021-05-17 14:30                         ` [Intel-gfx] " Daniel Vetter
2021-05-17 14:39                         ` Nieto, David M
2021-05-17 14:39                           ` [Intel-gfx] " Nieto, David M
2021-05-17 16:00                           ` Tvrtko Ursulin
2021-05-17 16:00                             ` [Intel-gfx] " Tvrtko Ursulin
2021-05-17 18:02                             ` Nieto, David M
2021-05-17 18:02                               ` [Intel-gfx] " Nieto, David M
2021-05-17 18:16                               ` Nieto, David M [this message]
2021-05-17 18:16                                 ` Nieto, David M
2021-05-17 18:16                                 ` Nieto, David M
2021-05-17 19:03                                 ` [Nouveau] " Simon Ser
2021-05-17 19:03                                   ` [Intel-gfx] " Simon Ser
2021-05-17 19:03                                   ` Simon Ser
2021-05-18  9:08                                   ` [Nouveau] " Tvrtko Ursulin
2021-05-18  9:08                                     ` [Intel-gfx] " Tvrtko Ursulin
2021-05-18  9:08                                     ` Tvrtko Ursulin
2021-05-18  9:16                                     ` [Nouveau] " Daniel Stone
2021-05-18  9:16                                       ` [Intel-gfx] " Daniel Stone
2021-05-18  9:16                                       ` Daniel Stone
2021-05-18  9:40                                       ` [Nouveau] " Tvrtko Ursulin
2021-05-18  9:40                                         ` [Intel-gfx] " Tvrtko Ursulin
2021-05-18  9:40                                         ` Tvrtko Ursulin
2021-05-19 16:16                                         ` [Nouveau] " Tvrtko Ursulin
2021-05-19 16:16                                           ` [Intel-gfx] " Tvrtko Ursulin
2021-05-19 16:16                                           ` Tvrtko Ursulin
2021-05-19 18:23                                           ` [Nouveau] [Intel-gfx] " Daniel Vetter
2021-05-19 18:23                                             ` Daniel Vetter
2021-05-19 18:23                                             ` Daniel Vetter
2021-05-19 23:17                                             ` [Nouveau] " Nieto, David M
2021-05-19 23:17                                               ` Nieto, David M
2021-05-19 23:17                                               ` Nieto, David M
2021-05-20 14:11                                               ` [Nouveau] " Daniel Vetter
2021-05-20 14:11                                                 ` Daniel Vetter
2021-05-20 14:11                                                 ` Daniel Vetter
2021-05-20 14:12                                                 ` [Nouveau] " Christian König
2021-05-20 14:12                                                   ` Christian König
2021-05-20 14:12                                                   ` Christian König
2021-05-20 14:17                                                   ` [Nouveau] " arabek
2021-05-20 14:17                                                     ` [Intel-gfx] [Nouveau] " arabek
2021-05-20 14:17                                                     ` [Nouveau] [Intel-gfx] " arabek
2021-05-20  8:35                                             ` Tvrtko Ursulin
2021-05-20  8:35                                               ` Tvrtko Ursulin
2021-05-20  8:35                                               ` Tvrtko Ursulin
2021-05-24 10:48                                               ` [Nouveau] " Tvrtko Ursulin
2021-05-24 10:48                                                 ` Tvrtko Ursulin
2021-05-24 10:48                                                 ` Tvrtko Ursulin
2021-05-18  9:35                               ` Tvrtko Ursulin
2021-05-18  9:35                                 ` [Intel-gfx] " Tvrtko Ursulin
2021-05-18 12:06                                 ` Christian König
2021-05-18 12:06                                   ` [Intel-gfx] " Christian König
2021-05-17 19:16                         ` Christian König
2021-05-17 19:16                           ` [Intel-gfx] " Christian König
2021-06-28 10:16                       ` Tvrtko Ursulin
2021-06-28 10:16                         ` [Intel-gfx] " Tvrtko Ursulin
2021-06-28 14:37                         ` Daniel Vetter
2021-06-28 14:37                           ` [Intel-gfx] " Daniel Vetter
2021-05-15 10:40                     ` Maxime Schmitt
2021-05-17 16:13                       ` Tvrtko Ursulin
2021-05-17 14:20   ` Daniel Vetter
2021-05-17 14:20     ` [Intel-gfx] " Daniel Vetter
2021-05-13 16:38 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for " Patchwork

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=BYAPR12MB284090FAC1C6E149F0A1A0ECF42D9@BYAPR12MB2840.namprd12.prod.outlook.com \
    --to=david.nieto@amd.com \
    --cc=Christian.Koenig@amd.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=alexdeucher@gmail.com \
    --cc=aritger@nvidia.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jhubbard@nvidia.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is 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.