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 <[email protected]>
Cc: Ludovico de Nittis <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Christian König <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Simona Vetter <[email protected]>

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(-)



Reply via email to