Re: On kernel interfaces for a GPU top

[Tvrtko Ursulin]

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