Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > 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. Well, it is somewhat embarrassing for me that this is described by the lower half of the commit message... >> 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 :) Indeed, there is none. Reviewed-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
