Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of exposing
process info in there. To clarify, my patch is not exposing sysfs
entry per process, but one per open drm fd.
Yes, we discussed this as well, but then rejected the approach.
To have useful information related to the open drm fd you need to
related that to process(es) which have that file descriptor open.
Just tracking who opened it first like DRM does is pretty useless on
modern systems.
We do update the pid/name for fds passed over unix sockets.
Well I just double checked and that is not correct.
Could be that i915 has some special code for that, but on my laptop I
only see the X server under the "clients" debugfs file.
But an "lsof /dev/dri/renderD128" for example does exactly what top
does as well, it iterates over /proc and sees which process has that
file open.
Lsof is quite inefficient for this use case. It has to open _all_ open
files for _all_ processes on the system to find a handful of ones
which may have the DRM device open.
Completely agree.
The key point is you either need to have all references to an open fd,
or at least track whoever last used that fd.
At least the last time I looked even the fs layer didn't know which fd
is open by which process. So there wasn't really any alternative to the
lsof approach.
Regards,
Christian.
So even with sysfs aid for discovery you are back to just going over
all files again.
For what use case?
To enable GPU usage in top we can do much better than iterate over all
open files in the system. We can start with a process if going with
the /proc proposal, or with the opened DRM file directly with the
sysfs proposal. Both are significantly fewer than total number of open
files across all processes.
Regards,
Tvrtko
