CPU overhead for drm fdinfo stats

[Tvrtko Ursulin]

On 27/07/2023 21:58, Alex Deucher wrote:
> We have a number of customers using these stats, but the issue that
> keeps coming up is the CPU overhead to gather them, particularly on
> systems with hundreds of processes using the GPU.  Has anyone given
> any thought to having a single interface to get this information for
> the entire GPU in one place?

Could I have a framed told you so certificate please? :D

Well at least it depends on how much CPU overhead would your users be 
happy to eliminate and how much to keep. So maybe no need for that 
certificate just yet.

I was raising the issue of exponential complexity of walking "total 
number of processes" x "total number of file descriptors" on a system 
from the inception of fdinfo.

So for that issue the idea was to perhaps expose a list of pids with DRM 
fds open somewhere, maybe sysfs.

That would eliminate walking _all_ processes and trying to parse any 
their file descriptor.

But it would still require walking all file descriptors belonging to 
processes with DRM fds open.

If that wouldn't be enough of a saving for your users then no, I am not 
aware it was discussed. Assuming at least you were suggesting something 
like "read all fdinfo for all clients" in one blob. Also in sysfs? I 
think it would be doable by walking the dev->filelist and invoking 
drm_show_fdinfo() on them.

Out of curiosity are they using the fdinfo parsing code from IGT or 
something of their own?

Regards,

Tvrtko