[Intel-gfx] [PATCH 1/2] drm/i915: Use our singlethreaded wq for freeing objects

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-15 16:54:57)
>
> In general it is a bit funky to call_rcu to schedule worker - what would
> be the difference to just queueing the worker which would have
> synchronize rcu in it?

The complication came from introducing the direct cleanup path to
penalise frequent reallocations, and to avoid deferring unbounded work
to the rcu task (which shows up in our microbenchmarks as a significant
drawback).

> Or would it be feasible to do multi-pass - 1st pass directly from
> call_rcu does the ones which can be done wo/ struct mutex, leaves the
> rest on the list and queues more thorough 2nd pass. Haven't really
> investigated it, just throwing ideas around.

We need to take the mutex first in the release pass (to release the GPU
binding before we return the resources back to the system). There is a
nicety in doing most of the operations in the worker context rather than
in process (deferring the work to later, with some penalty applied to
frequent reallocation) or rcu context.
-Chris