On 18/05/2021 10:40, Tvrtko Ursulin wrote:>
> On 18/05/2021 10:16, Daniel Stone wrote:
>> Hi,
>>
>> On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
>> <tvrtko.ursulin at linux.intel.com> wrote:
>>> I was just wondering if stat(2) and a chrdev major check would be a
>>> solid criteria to more efficiently (compared to parsing the text
>>> content) detect drm files while walking procfs.
>>
>> Maybe I'm missing something, but is the per-PID walk actually a
>> measurable performance issue rather than just a bit unpleasant?
>
> Per pid and per each open fd.
>
> As said in the other thread what bothers me a bit in this scheme is that
> the cost of obtaining GPU usage scales based on non-GPU criteria.
>
> For use case of a top-like tool which shows all processes this is a
> smaller additional cost, but then for a gpu-top like tool it is somewhat
> higher.
To further expand, not only cost would scale per pid multiplies per open
fd, but to detect which of the fds are DRM I see these three options:
1) Open and parse fdinfo.
2) Name based matching ie /dev/dri/.. something.
3) Stat the symlink target and check for DRM major.
All sound quite sub-optimal to me.
Name based matching is probably the least evil on system resource usage
(Keeping the dentry cache too hot? Too many syscalls?), even though
fundamentally I don't it is the right approach.
What happens with dup(2) is another question.
Does anyone have any feedback on the /proc/<pid>/gpu idea at all?
Regards,
Tvrtko