[Intel-gfx] [PATCH v6 14/25] drm/i915: Manually unwind after a failed request allocation

Chris Wilson chris at chris-wilson.co.uk
Wed Apr 27 12:58:16 UTC 2016


On Wed, Apr 27, 2016 at 01:51:38PM +0100, Tvrtko Ursulin wrote:
> 
> On 26/04/16 21:06, Chris Wilson wrote:
> >In the next patches, we want to move the work out of freeing the request
> >and into its retirement (so that we can free the request without
> >requiring the struct_mutex). This means that we cannot rely on
> >unreferencing the request to completely teardown the request any more
> >and so we need to manually unwind the failed allocation. In doing so, we
> >reorder the allocation in order to make the unwind simple (and ensure
> >that we don't try to unwind a partial request that may have modified
> >global state) and so we end up pushing the initial preallocation down
> >into the engine request initialisation functions where we have the
> >requisite control over the state of the request.
> >
> >Moving the initial preallocation into the engine is less than ideal: it
> >moves logic to handle a specific problem with request handling out of
> >the common code. On the other hand, it does allow those backends
> >significantly more flexibility in performing its allocations.
> 
> Could add _free_request_extras which would only be allowed to be
> called from _alloc_request? That would enable not-polluting the
> engine with common code I think.

If you look at where I think it should be placed inside lrc, then we
need multiple phases. Not that isn't much of a big deal:

request_alloc:

	engine->pin_request()

	/* prep */

	engine->init_context()

are more or less what we need, it will take a bit of organisation to
align legacy / execlists. But it can be done.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list