lkml.org 
[lkml]   [2019]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v6 08/18] drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing
On Thu, Jul 4, 2019 at 11:46 AM Chia-I Wu <olvaffe@gmail.com> wrote:
>
> On Thu, Jul 4, 2019 at 4:25 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > Hi,
> >
> > > > if (fence)
> > > > virtio_gpu_fence_emit(vgdev, hdr, fence);
> > > > + if (vbuf->objs) {
> > > > + virtio_gpu_array_add_fence(vbuf->objs, &fence->f);
> > > > + virtio_gpu_array_unlock_resv(vbuf->objs);
> > > > + }
> > > This is with the spinlock held. Maybe we should move the
> > > virtio_gpu_array_unlock_resv call out of the critical section.
> >
> > That would bring back the race ...
> Right...
> >
> > > I am actually more concerned about virtio_gpu_array_add_fence, but it
> > > is also harder to move. Should we add a kref to the object array?
> >
> > Yep, refcounting would be the other way to fix the race.
> >
> > > This bothers me because I recently ran into a CPU-bound game with very
> > > bad lock contention here.
> >
> > Hmm. Any clue where this comes from? Multiple threads competing for
> > virtio buffers I guess? Maybe we should have larger virtqueues?
> The game was single-threaded. I guess it was the game and Xorg
> competing for virtio buffers. That was also on an older kernel
> without explicit fences. The userspace had to create dummy resources
> frequently to do VIRTIO_IOCTL_RESOURCE_WAIT.
>
> I think this is fine for now as far as I am concerned. I can look
> into this more closely after this series lands.
It was virtio_gpu_dequeue_ctrl_func who wanted to grab the lock to
handle the responses. I sent a patch for it

https://patchwork.freedesktop.org/series/63529/

>
>
> >
> > cheers,
> > Gerd
> >

\
 
 \ /
  Last update: 2019-07-11 04:36    [W:0.060 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site