On 23/02/2026 19:19, Francis, David wrote:
[AMD Official Use Only - AMD Internal Distribution Only]
We would like to have a GPU equivalent of top; some program that can
efficiently get a list of processes using the GPU (or other drm driver)
and some basic usage statistics for those processes.
We would like this program to be usable by processes with no particular
privileges, in particular processes without ptrace permissions on the
other processes using the GPU (which are needed for fdinfo).
There are two main problems
1: There's no way for an unprivileged process to get this kind of data.
There's fdinfo and debugfs, which can contain process-specific data, but
aren't accessible without privileges. There's drm sysfs, which can be
accessed by anyone (at least parially) but can't contain process-
specific data.
Just my 2c.
I think a fair number of interested parties wants this but so far no one
proposed exactly what and where to put it. It would be interesting to
hear what proposal you have in mind.
2: There's no efficient way for any process to easily get a list of
which processes are using the GPU. This information is available by
looking through the fdinfo entries for every process, but that's slow.
drm drivers can track which process created a fd on the device file, and
Lets call this 2a). Yep, this too is a long standing issue. It would be
nice to tie 1+2a) into a solution.
which process last called an ioctl on an fd, but the process that
actually holds the fd might be neither of those. (e.g. X server opens a
drm driver, starts some queues, then forks, handing the fd to a child
process that then submits to the queues but never does any more ioctls)
This is 2b) right?
What do you mean by "actually _holds_"? The actual most recent ioctl
user? This is already tracked in the DRM core. See drm_file_update_pid()
and it's caller. Used from debugfs, error logging, error capture from at
least some drivers. So those one will already have the "real" fd user
info displayed correctly.
How to tie that with the new 1+2a) interface is the question.
Regards,
Tvrtko
As a solution for problem 1, we have as a possible idea making some
fdinfo entries accessible without ptrace priviliges; I would like to
know if there are any immediate objections to that.
As for problem 2, I really don't know what kind of interface would be
accessible and am open to ideas.
Thanks,
David Francis
