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

[Mika Kuoppala <mika.kuoppala@linux.intel.com>]

Chris Wilson <chris@chris-wilson.co.uk> writes:

> Quoting Mika Kuoppala (2020-02-07 09:13:22)
>> Chris Wilson <chris@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.

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@linux.intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx