Hello, Indeed it’s not efficient but that’s the only exposed way we have to retrieve the information at this point (for drm drivers exposing metrics through fdinfo). It doesn’t require any extra privileges if one is only interested in the user owned processes (which is most use cases as far as I know).
I think that there was a discussion at some years ago from Intel on the kernel mailing list to expose the process list using drm. Maybe having a way to query which processes (and file descriptor) use drm and then only going through the relevant fdinfo files would alleviate most of the inefficiencies (modulo privilege problems for other user processes). Also I haven’t implemented use cases where the GPU doesn’t use DRM, e.g., AMD CDNA that is going through rocm (I don’t have access to a card to test it). I also noticed some instances, where the driver doesn’t report any usage, although it’s actually using the encode/decode engine through VA-API with a DRM handle. Cheers, Maxime > On 6 Feb 2026, at 14:38, Christian König <[email protected]> wrote: > > On 2/5/26 20:25, Natalie Vock wrote: >>> On 2/5/26 19:58, Alex Deucher wrote: >>> Has anyone given any thought on how to support something like top for >>> accelerators or GPUs? >> >> top for accelerators/GPUs kind of exists already, see [1] or [2]. >> Clearly, this problem has some kind of solution (looking through the code, >> it seems like they check every fd if it has a DRM fdinfo file associated >> (which is indeed not particularly efficient)). >> >> Maybe it's worth asking the authors of the respective tools for their >> opinions here? > > That is a really good point. Adding Maxime Schmitt and Umio Yasuno on CC. > > Let's hope I've picked the correct mail addresses. > > Christian. > >> >> Natalie >> >> [1] https://github.com/Umio-Yasuno/amdgpu_top >> [2] https://github.com/Syllo/nvtop >>> We have fdinfo, but using fdinfo requires extra >>> privileges (CAP_SYS_PTRACE) and there is not a particularly efficient >>> way to even discover what processes are using the GPU. There is the >>> clients list in debugfs, but that is also admin only. Tools like ps >>> and top use /proc/<pid>/stat and statm. Do you think there would be >>> an appetite for something like /proc/<pid>/drm/stat, statm, etc.? >>> This would duplicate much of what is in fdinfo, but would be available >>> to regular users. >>> >>> Thanks, >>> >>> Alex >> >
