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