Re: [PATCH 0/7] Per client engine busyness

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 28, 2021 at 12:18 PM Tvrtko Ursulin
<tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote:
>
>
>
> On 14/05/2021 16:10, Christian König wrote:
> > Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin:
> >>
> >> On 14/05/2021 15:56, Christian König wrote:
> >>> 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.
> >>
> >> Yes we have special code in i915 for this. Part of this series we are
> >> discussing here.
> >
> > Ah, yeah you should mention that. Could we please separate that into
> > common code instead? Cause I really see that as a bug in the current
> > handling independent of the discussion here.
>
> What we do in i915 is update the pid and name when a task different to
> the one which opened the fd does a GEM context create ioctl.
>
> Moving that to DRM core would be along the lines of doing the same check
> and update on every ioctl. Maybe allow the update to be one time only if
> that would work. Would this be desirable and acceptable? If so I can
> definitely sketch it out.

If we go with fdinfo for these it becomes clear who all owns the file,
since it's then a per-process thing. Not sure how much smarts we
should have for internal debugfs output. Maybe one-shot update on
first driver ioctl (since if you're on render nodes then X does the
drm auth dance, so "first ioctl" is wrong).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux