From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Rob Clark <robdclark@gmail.com>
Cc: "Daniel Vetter" <daniel.vetter@ffwll.ch>,
Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
"Alex Deucher" <alexdeucher@gmail.com>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
Date: Tue, 18 Apr 2023 15:45:59 +0100 [thread overview]
Message-ID: <8a16f714-d20a-7608-a08f-88b20dc05d86@linux.intel.com> (raw)
In-Reply-To: <CAF6AEGu+AbQnPV-1goqJi_RJR7TB8Ta5FXTKn-j6Aq4fiuPN2w@mail.gmail.com>
On 18/04/2023 15:36, Rob Clark wrote:
> On Tue, Apr 18, 2023 at 7:19 AM Tvrtko Ursulin
> <tvrtko.ursulin@linux.intel.com> wrote:
>>
>>
>> On 18/04/2023 14:49, Rob Clark wrote:
>>> On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin
>>> <tvrtko.ursulin@linux.intel.com> wrote:
>>>>
>>>>
>>>> On 17/04/2023 20:39, Rob Clark wrote:
>>>>> On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
>>>>> <tvrtko.ursulin@linux.intel.com> wrote:
>>>>>>
>>>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>>
>>>>>> Add support to dump GEM stats to fdinfo.
>>>>>>
>>>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>> ---
>>>>>> Documentation/gpu/drm-usage-stats.rst | 12 +++++++
>>>>>> drivers/gpu/drm/drm_file.c | 52 +++++++++++++++++++++++++++
>>>>>> include/drm/drm_drv.h | 7 ++++
>>>>>> include/drm/drm_file.h | 8 +++++
>>>>>> 4 files changed, 79 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst
>>>>>> index 2ab32c40e93c..8273a41b2fb0 100644
>>>>>> --- a/Documentation/gpu/drm-usage-stats.rst
>>>>>> +++ b/Documentation/gpu/drm-usage-stats.rst
>>>>>> @@ -21,6 +21,7 @@ File format specification
>>>>>>
>>>>>> - File shall contain one key value pair per one line of text.
>>>>>> - Colon character (`:`) must be used to delimit keys and values.
>>>>>> +- Caret (`^`) is also a reserved character.
>>>>>
>>>>> this doesn't solve the problem that led me to drm-$CATEGORY-memory... ;-)
>>>>
>>>> Could you explain or remind me with a link to a previous explanation?
>>>
>>> How is userspace supposed to know that "drm-memory-foo" is a memory
>>> type "foo" but drm-memory-foo^size is not memory type "foo^size"?
>>
>> Are you referring to nvtop?
>
> I'm not referring to any particular app. It could even be some app
> that isn't even written yet but started with an already existing
> kernel without this change. It is just a general point about forwards
> compatibility of old userspace with new kernel. And it doesn't really
> matter what special character you use. You can't retroactively define
> some newly special characters.
What you see does not work if we output both legacy and new key with
extra category? Userspace which hardcode the name keep working, and
userspace which parses region names as opaque strings also keeps working
just shows more entries.
Regards,
Tvrtko
>
> BR,
> -R
>
>> Indeed that one hardcodes:
>>
>> static const char drm_amdgpu_vram[] = "drm-memory-vram";
>>
>> And does brute strcmp on it:
>>
>> } else if (!strcmp(key, drm_amdgpu_vram_old) || !strcmp(key, drm_amdgpu_vram)) {
>>
>> So okay for that one, if we need to keep it working I just change this in my RFC:
>>
>> """
>> Resident category is identical to the drm-memory-<str> key and two should be
>> mutually exclusive.
>> """
>>
>> Into this:
>>
>> """
>> Resident category is identical to the drm-memory-<str> key and where the categorized one is present the legacy one must be too in order to preserve backward compatibility.
>> """
>>
>> Addition to my RFC:
>>
>> ...
>> for (i = 0; i < num; i++) {
>> if (!regions[i]) /* Allow sparse name arrays. */
>> continue;
>>
>> print_stat(p, "size", regions[i], stats[i].size);
>> print_stat(p, "shared", regions[i], stats[i].shared);
>> + print_stat(p, "", regions[i], stats[i].resident);
>> print_stat(p, "resident", regions[i], stats[i].resident);
>> print_stat(p, "purgeable", regions[i], stats[i].purgeable);
>> print_stat(p, "active", regions[i], stats[i].active);
>> }
>> ...
>>
>> Results in output like this (in theory, if/when amdgpu takes on the extended format):
>>
>> drm-memory-vram-size: ... KiB
>> drm-memory-vram: $same KiB
>> drm-memory-vram-resident: $same KiB
>> drm-memory-vram-...:
>>
>> Regards,
>>
>> Tvrtko
>>
>> P.S. Would a slash instead of a caret be prettier?
>>
>>>> What tool barfs on it and how? Spirit of drm-usage-stats.pl is that for
>>>> both drm-engine-<str>: and drm-memory-<str>: generic userspace is
>>>> supposed to take the whole <std> as opaque and just enumerate all it finds.
>>>>
>>>> Gputop manages to do that with engines names it knows _nothing_ about.
>>>> If it worked with memory regions it would just show the list of new
>>>> regions as for example "system^resident", "system^active". Then tools
>>>> can be extended to understand it better and provide a sub-breakdown if
>>>> wanted.
>>>>
>>>> Ugly not, we can change from caret to something nicer, unless I am
>>>> missing something it works, no?
>>>>
>>>> Regards,
>>>>
>>>> Tvrtko
>>>>
>>>>>
>>>>> (also, it is IMHO rather ugly)
>>>>>
>>>>> BR,
>>>>> -R
>>>>>
>>>>>> - All keys shall be prefixed with `drm-`.
>>>>>> - Whitespace between the delimiter and first non-whitespace character shall be
>>>>>> ignored when parsing.
>>>>>> @@ -105,6 +106,17 @@ object belong to this client, in the respective memory region.
>>>>>> Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
>>>>>> indicating kibi- or mebi-bytes.
>>>>>>
>>>>>> +- drm-memory-<str>^size: <uint> [KiB|MiB]
>>>>>> +- drm-memory-<str>^shared: <uint> [KiB|MiB]
>>>>>> +- drm-memory-<str>^resident: <uint> [KiB|MiB]
>>>>>> +- drm-memory-<str>^purgeable: <uint> [KiB|MiB]
>>>>>> +- drm-memory-<str>^active: <uint> [KiB|MiB]
>>>>>> +
>>>>>> +Resident category is identical to the drm-memory-<str> key and two should be
>>>>>> +mutually exclusive.
>>>>>> +
>>>>>> +TODO more description text...
>>>>>> +
>>>>>> - drm-cycles-<str> <uint>
>>>>>>
>>>>>> Engine identifier string must be the same as the one specified in the
>>>>>> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
>>>>>> index 37b4f76a5191..e202f79e816d 100644
>>>>>> --- a/drivers/gpu/drm/drm_file.c
>>>>>> +++ b/drivers/gpu/drm/drm_file.c
>>>>>> @@ -42,6 +42,7 @@
>>>>>> #include <drm/drm_client.h>
>>>>>> #include <drm/drm_drv.h>
>>>>>> #include <drm/drm_file.h>
>>>>>> +#include <drm/drm_gem.h>
>>>>>> #include <drm/drm_print.h>
>>>>>>
>>>>>> #include "drm_crtc_internal.h"
>>>>>> @@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev, struct drm_pending_event *e)
>>>>>> }
>>>>>> EXPORT_SYMBOL(drm_send_event);
>>>>>>
>>>>>> +static void
>>>>>> +print_stat(struct drm_printer *p, const char *stat, const char *region, u64 sz)
>>>>>> +{
>>>>>> + const char *units[] = {"", " KiB", " MiB"};
>>>>>> + unsigned int u;
>>>>>> +
>>>>>> + if (sz == ~0ull) /* Not supported by the driver. */
>>>>>> + return;
>>>>>> +
>>>>>> + for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
>>>>>> + if (sz < SZ_1K)
>>>>>> + break;
>>>>>> + sz = div_u64(sz, SZ_1K);
>>>>>> + }
>>>>>> +
>>>>>> + drm_printf(p, "drm-memory-%s^%s:\t%llu%s\n",
>>>>>> + region, stat, sz, units[u]);
>>>>>> +}
>>>>>> +
>>>>>> +static void print_memory_stats(struct drm_printer *p, struct drm_file *file)
>>>>>> +{
>>>>>> + struct drm_device *dev = file->minor->dev;
>>>>>> + struct drm_fdinfo_memory_stat *stats;
>>>>>> + unsigned int num, i;
>>>>>> + char **regions;
>>>>>> +
>>>>>> + regions = dev->driver->query_fdinfo_memory_regions(dev, &num);
>>>>>> +
>>>>>> + stats = kcalloc(num, sizeof(*stats), GFP_KERNEL);
>>>>>> + if (!stats)
>>>>>> + return;
>>>>>> +
>>>>>> + dev->driver->query_fdinfo_memory_stats(file, stats);
>>>>>> +
>>>>>> + for (i = 0; i < num; i++) {
>>>>>> + if (!regions[i]) /* Allow sparse name arrays. */
>>>>>> + continue;
>>>>>> +
>>>>>> + print_stat(p, "size", regions[i], stats[i].size);
>>>>>> + print_stat(p, "shared", regions[i], stats[i].shared);
>>>>>> + print_stat(p, "resident", regions[i], stats[i].resident);
>>>>>> + print_stat(p, "purgeable", regions[i], stats[i].purgeable);
>>>>>> + print_stat(p, "active", regions[i], stats[i].active);
>>>>>> + }
>>>>>> +
>>>>>> + kfree(stats);
>>>>>> +}
>>>>>> +
>>>>>> /**
>>>>>> * drm_show_fdinfo - helper for drm file fops
>>>>>> * @seq_file: output stream
>>>>>> @@ -900,6 +949,9 @@ void drm_show_fdinfo(struct seq_file *m, struct file *f)
>>>>>>
>>>>>> if (dev->driver->show_fdinfo)
>>>>>> dev->driver->show_fdinfo(&p, file);
>>>>>> +
>>>>>> + if (dev->driver->query_fdinfo_memory_regions)
>>>>>> + print_memory_stats(&p, file);
>>>>>> }
>>>>>> EXPORT_SYMBOL(drm_show_fdinfo);
>>>>>>
>>>>>> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
>>>>>> index 89e2706cac56..ccc1cd98d2aa 100644
>>>>>> --- a/include/drm/drm_drv.h
>>>>>> +++ b/include/drm/drm_drv.h
>>>>>> @@ -35,6 +35,7 @@
>>>>>> #include <drm/drm_device.h>
>>>>>>
>>>>>> struct drm_file;
>>>>>> +struct drm_fdinfo_memory_stat;
>>>>>> struct drm_gem_object;
>>>>>> struct drm_master;
>>>>>> struct drm_minor;
>>>>>> @@ -408,6 +409,12 @@ struct drm_driver {
>>>>>> */
>>>>>> void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
>>>>>>
>>>>>> + char ** (*query_fdinfo_memory_regions)(struct drm_device *dev,
>>>>>> + unsigned int *num);
>>>>>> +
>>>>>> + void (*query_fdinfo_memory_stats)(struct drm_file *f,
>>>>>> + struct drm_fdinfo_memory_stat *stat);
>>>>>> +
>>>>>> /** @major: driver major number */
>>>>>> int major;
>>>>>> /** @minor: driver minor number */
>>>>>> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
>>>>>> index 7d9b3c65cbc1..00d48beeac5c 100644
>>>>>> --- a/include/drm/drm_file.h
>>>>>> +++ b/include/drm/drm_file.h
>>>>>> @@ -375,6 +375,14 @@ struct drm_file {
>>>>>> #endif
>>>>>> };
>>>>>>
>>>>>> +struct drm_fdinfo_memory_stat {
>>>>>> + u64 size;
>>>>>> + u64 shared;
>>>>>> + u64 resident;
>>>>>> + u64 purgeable;
>>>>>> + u64 active;
>>>>>> +};
>>>>>> +
>>>>>> /**
>>>>>> * drm_is_primary_client - is this an open file of the primary node
>>>>>> * @file_priv: DRM file
>>>>>> --
>>>>>> 2.37.2
>>>>>>
next prev parent reply other threads:[~2023-04-18 14:46 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-17 15:56 [Intel-gfx] [RFC 0/6] fdinfo alternative memory stats proposal Tvrtko Ursulin
2023-04-17 15:56 ` [Intel-gfx] [RFC 1/6] drm: Add common fdinfo helper Tvrtko Ursulin
2023-04-17 15:56 ` [Intel-gfx] [RFC 2/6] drm/i915: Use the " Tvrtko Ursulin
2023-04-17 15:56 ` [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats Tvrtko Ursulin
2023-04-17 16:20 ` Christian König
2023-04-18 10:47 ` Tvrtko Ursulin
2023-04-18 14:16 ` Rob Clark
2023-04-17 19:39 ` Rob Clark
2023-04-18 8:59 ` Tvrtko Ursulin
2023-04-18 13:49 ` Rob Clark
2023-04-18 14:18 ` Tvrtko Ursulin
2023-04-18 14:36 ` Rob Clark
2023-04-18 14:45 ` Tvrtko Ursulin [this message]
2023-04-18 16:13 ` Rob Clark
2023-04-18 16:44 ` Tvrtko Ursulin
2023-04-18 17:10 ` Rob Clark
2023-04-17 15:56 ` [Intel-gfx] [RFC 4/6] drm: Add simple fdinfo memory helpers Tvrtko Ursulin
2023-04-18 17:18 ` Rob Clark
2023-04-19 13:16 ` Tvrtko Ursulin
2023-04-19 14:32 ` Rob Clark
2023-04-20 13:14 ` Tvrtko Ursulin
2023-04-21 1:24 ` Rob Clark
2023-04-17 15:56 ` [Intel-gfx] [RFC 5/6] drm/msm: Add basic memory stats Tvrtko Ursulin
2023-04-17 15:56 ` [Intel-gfx] [RFC 6/6] drm/i915: Implement fdinfo memory stats printing Tvrtko Ursulin
2023-04-18 14:39 ` Rob Clark
2023-04-18 14:58 ` Tvrtko Ursulin
2023-04-18 16:08 ` Rob Clark
2023-04-19 14:06 ` Tvrtko Ursulin
2023-04-19 14:38 ` Rob Clark
2023-04-20 13:11 ` Tvrtko Ursulin
2023-04-21 1:26 ` Rob Clark
2023-04-17 19:54 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for fdinfo alternative memory stats proposal Patchwork
2023-04-17 19:54 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-04-17 20:05 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-04-18 7:21 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=8a16f714-d20a-7608-a08f-88b20dc05d86@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=alexdeucher@gmail.com \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=robdclark@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox