From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
To: "Christian König" <christian.koenig@amd.com>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: kernel-dev@igalia.com, "Maíra Canal" <mcanal@igalia.com>,
"Ludovico de Nittis" <ludovico.denittis@collabora.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>
Subject: Re: [RFC 0/2] DRM standardized memory stats
Date: Sat, 3 Oct 2026 09:36:18 +0100 [thread overview]
Message-ID: <401fd882-e9c8-44c5-9497-31ea6b8a596a@igalia.com> (raw)
In-Reply-To: <5e0949d4-85a2-4519-9e3e-a1b01ae58f46@amd.com>
On 21/09/2026 10:19, Christian König wrote:
> On 9/17/26 14:04, Tvrtko Ursulin wrote:
>> Re-floating a simple idea (this time with more Cc) born from an user interest to
>> be able to correctly size the swap space during OS installation, based on the
>> size of the VRAM a discrete GPU might have. And to be able to do it in a vendor
>> agnostic way.
>>
>> Idea is to expose a standardized scheme in sysfs, under the DRM class card, and
>> under a new 'memstat' directory. Such as, example from amdgpu:
>>
>> /sys/class/drm/card1/memstat/
>> ├── gtt
>> │ ├── total_mb
>> │ └── used_mb
>> └── vram
>> ├── total_mb
>> └── used_mb
>>
>> Or with concrete numbers:
>>
>> $ grep -Hr . /sys/class/drm/card1/memstat/
>> /sys/class/drm/card1/memstat/vram/total_mb:1024
>> /sys/class/drm/card1/memstat/vram/used_mb:445
>> /sys/class/drm/card1/memstat/gtt/total_mb:7394
>> /sys/class/drm/card1/memstat/gtt/used_mb:71
>>
>> Drivers need to implement a simple DRM driver level callback which needs to
>> report a stable list of interesting memory regions and their respective stats.
>> The region names then become sub-directory names under the new 'memstat'
>> directory, with each region exposing the total size and the current usage.
>>
>> Similar data can already be queried if the dmem cgroup controller is enabled,
>> also only for the participating drivers, by querying the root cgroup. But
>> perhaps sysfs is easier, or perhaps it is too much code for too little benefit.
>> I am curious to hear any opinions.
>
> The implementation can be polished a bit but I seriously like the idea to standardize that.
Indeed. I think I've fixed all the kobject related flaring bugs locally.
> amdgpu already exposes the information as non-standard sysfs files and adds a bit more, e.g. CPU visible VRAM size, VRAM vendor etc...
>
> I'm wondering if those shouldn't be added as well and the existing sysfs files then implemented as symlinks.
CPU visible I guess could be added with a small addition to the 2nd
(amdgpu) patch. So far the implementation is driven trivially from TTM
placements / range managers, but I could easily add a different stat
since drivers define what they export.
Existing files as symlinks I do not know who I would implement it. File
to file is not possible AFAIU, right?
Allowing drivers to put custom files in there might be complicated and
could create a standardization problem. If vendor is strongly desired I
could add it as DRM owned attribute perhaps. Like
/sys/class/drm/card1/memstat/vram/hw_vendor or something.
Regards,
Tvrtko
>> Cc: Maíra Canal <mcanal@igalia.com>
>> Cc: Ludovico de Nittis <ludovico.denittis@collabora.com>
>> Cc: Alex Deucher <alexander.deucher@amd.com>
>> Cc: Christian König <christian.koenig@amd.com>
>> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> Cc: Maxime Ripard <mripard@kernel.org>
>> Cc: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: David Airlie <airlied@gmail.com>
>> Cc: Simona Vetter <simona@ffwll.ch>
>>
>> Tvrtko Ursulin (2):
>> drm: Allow drivers to report standardized memory stats
>> drm/amdgpu: Wire up DRM memory stats reporting
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 6 +
>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
>> drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 40 +++++--
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 37 +++++++
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 +
>> drivers/gpu/drm/drm_drv.c | 10 ++
>> drivers/gpu/drm/drm_sysfs.c | 123 +++++++++++++++++++++
>> include/drm/drm_device.h | 19 ++++
>> include/drm/drm_drv.h | 8 ++
>> include/drm/drm_file.h | 9 ++
>> include/drm/drm_sysfs.h | 4 +
>> 11 files changed, 248 insertions(+), 13 deletions(-)
>>
>
next prev parent reply other threads:[~2026-10-03 8:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 12:04 [RFC 0/2] DRM standardized memory stats Tvrtko Ursulin
2026-09-17 12:04 ` [RFC 1/2] drm: Allow drivers to report " Tvrtko Ursulin
2026-09-17 12:14 ` sashiko-bot
2026-09-17 12:38 ` Thomas Zimmermann
2026-09-18 7:44 ` Tvrtko Ursulin
2026-09-17 12:04 ` [RFC 2/2] drm/amdgpu: Wire up DRM memory stats reporting Tvrtko Ursulin
2026-09-17 12:15 ` sashiko-bot
2026-09-21 9:19 ` [RFC 0/2] DRM standardized memory stats Christian König
2026-10-03 8:36 ` Tvrtko Ursulin [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-04-29 13:06 Tvrtko Ursulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=401fd882-e9c8-44c5-9497-31ea6b8a596a@igalia.com \
--to=tvrtko.ursulin@igalia.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel-dev@igalia.com \
--cc=ludovico.denittis@collabora.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mcanal@igalia.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is 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.