On 2/6/26 10:58, Tvrtko Ursulin wrote: > > On 05/02/2026 18:58, Alex Deucher wrote: >> Has anyone given any thought on how to support something like top for >> accelerators or GPUs? 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. > > In short yes, the inefficiency of the client discovery bugged me since the > start of fdinfo and it was discussed a few times how to improve it. > > AFAIR in those discussions a lists of clients outside of debugfs was > mentioned, since that would allow the cost of discovery to not scale by the > number of irrelevant processes. Something in proc was also mentioned but I > guess for both no one had a strong enough drive to actually do it.
The fundamental problem is that Linux only tracks in one direction who has which file open, but not the reverse. In other words even an lsof /dev/dri/render* does nothing else than going over /proc and seeing who has opened what. We can expose the list of open DRM connections and which process was the last user of each in sysfs (for example), but that is probably not accurate and might also expose information not every process should know about. Regards, Christian. > > Challenge will be finding the threads to see if there were any interesting > conclusions... The only one I can remember at the moment was this: > > https://lore.kernel.org/dri-devel/[email protected]/ > > It looks this attempt died out due proposing a binary interface in sysfs. > > In any case, I'd say it makes sense to do something. > > Regards, > > Tvrtko > > P.S. > Just in a case you did not see it, a generic tool exists as gputop in IGT but > as you say, you can only see data for processes the user running the tool can > read fdinfo stats of. And there some nicer tools feeding of the same data. >
