On Tue, Aug 4, 2020 at 4:08 PM Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
