[Intel-gfx] [PATCH 4/7] drm/i915: Delay the freeing of requests until retire time

[Chris Wilson]

On Mon, Jan 25, 2016 at 12:52:46PM +0100, Maarten Lankhorst wrote:
> Op 11-01-16 om 20:06 schreef John Harrison:
> > On 08/01/2016 22:08, Chris Wilson wrote:
> >> On Fri, Jan 08, 2016 at 06:47:25PM +0000, John.C.Harrison at Intel.com wrote:
> >>> From: John Harrison <John.C.Harrison at Intel.com>
> >>>
> >>> The request structure is reference counted. When the count reached
> >>> zero, the request was immediately freed and all associated objects
> >>> were unrefereced/unallocated. This meant that the driver mutex lock
> >>> must be held at the point where the count reaches zero. This was fine
> >>> while all references were held internally to the driver. However, the
> >>> plan is to allow the underlying fence object (and hence the request
> >>> itself) to be returned to other drivers and to userland. External
> >>> users cannot be expected to acquire a driver private mutex lock.
> >> It's a trivial issue to fix to enable freeing requests without holding the
> >> struct_mutex. You don't need to even add any new lists, delayed freeing
> >> mechanisms and whotnot.
> >> -Chris
> >>
> >
> > As the driver stands, it is not trivial to free a request without holding the mutex. It does things like unpinning buffers, freeing up contexts (which is a whole other bundle of complication), releasing IRQs. It may be possible to re-organise things to make those operations safe to do without the mutex but it certainly does not look trivial!
> Those things could be done as soon as the fence is signaled, doing it on free() is slightly too late..

Most recently

http://patchwork.freedesktop.org/patch/69900/

The caveat is that you need to teach execlists about the lifetime of its
contexts, which is also quite simple (and in the process takes yet
another step towards making execlist less special).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre