On Thu, Jul 4, 2019 at 11:46 AM Chia-I Wu <olvaffe@xxxxxxxxx> wrote:
>
> On Thu, Jul 4, 2019 at 4:25 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> 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
> >
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
