Quoting Mika Kuoppala (2020-02-07 09:13:22) > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
