Re: [Intel-gfx] [PATCH 11/66] drm/i915: Preallocate stashes for vma page-directories

Re: [Intel-gfx] [PATCH 11/66] drm/i915: Preallocate stashes for vma page-directories

[Daniel Vetter]

On Tue, Aug 4, 2020 at 4:08 PM Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Thomas Hellström (Intel) (2020-07-30 13:28:19)
> >
> > On 7/28/20 4:50 PM, Chris Wilson wrote:
> > >
> > > It's in the user critical path (the shortest path to perform their
> > > sequence of operations), but it's before the dma-fence itself. I say
> > > that's a particularly nasty false claim that it is not on the critical
> > > path, but being where it is circumvents the whole argument.
> > >
> >
> > Couldn't the following situation happen?
> >
> > 1. CS spawns userptr pinning work.
> > 2. CS creates and publishes a DMA-fence that depends on that pinning work.
>
> There's a break before 2 in that we do not publish a dma-fence on pending
> userptr work. There's no async wait on the userptr, if the pages are not
> available at the point of acquire, we hit an -EAGAIN, and take the
> flush_workqueue path until we stop hitting -EAGAIN.
>
> That is as painful as it sounds, and I claim that sitting and spinning in
> a user path is no better in terms of critical path than having it inside
> the dma-fence section. However, with this pretense we do not violate that
> rule.

You trade a deadlock for a livelock, and the livelock is limited fully
to the offending process using (too much) userptr, and the user can
break out of it with ^C. That's a fairly significant difference. Don't
overruse userptr still applies.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel