[Intel-gfx] [PATCH 1/4] drm/i915/gt: Prevent queuing retire workers on the virtual engine

Chris Wilson chris at chris-wilson.co.uk
Fri Feb 7 09:25:41 UTC 2020


Quoting Mika Kuoppala (2020-02-07 09:13:22)
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > Virtual engines are fleeting. They carry a reference count and may be freed
> > when their last request is retired. This makes them unsuitable for the
> > task of housing engine->retire.work so assert that it is not used.
> 
> There is chicken and egg problem here that I fail to grasp.

In the general case, an engine may be providing a workqueue for requests
for other engines. That's the conundrum I had in mind when writing that;
if and only if, we have the latest request from that engine on that
retire worker, then it will be protected by the last request (and our
careful ordering of dereferences). That is not guaranteed to be the case
(even for only virtual requests on a virtual engine, as we may not have
the last request queued for retirement, and so it may be retired ahead
of time.)

So as I write that, it becomes much clearer that there is a lifetime
issue with the concept of retirement queues on the virtual engine.

> If the retire work is the mechanism which triggers the request
> freeing, then the order should be fine. As the engine is still
> there for last request.

It's not the only mechanism, so concurrent retirements are expected.
 
> Or is the problem that it happens inside the worker which is inside
> the engine?

The immediate problem is that we didn't even set up the virtual engine to
have retirement queues :)
-Chris


More information about the Intel-gfx mailing list