[Intel-gfx] [PATCH 1/7] drm/i915/gtt: Defer address space cleanup to an RCU worker

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-06-19 15:51:18)
> 
> On 19/06/2019 12:23, Chris Wilson wrote:
> > Enable RCU protection of i915_address_space and its ppgtt superclasses,
> > and defer its cleanup into a worker executed after an RCU grace period.
> > 
> > In the future we will be able to use the RCU protection to reduce the
> > locking around VM lookups, but the immediate benefit is being able to
> > defer the release into a kworker (process context). This is required as
> > we may need to sleep to reap the WC pages stashed away inside the ppgtt.
> 
> I can't see that it adds RCU protection apart from using queue_rcu_work 
> for some reason.

That provides the RCU safe freeing, yes. My intentional is to use the
rcu read lock around the vm lookup + kref when dropping the struct_mutex
there.

> It _seems_ like it could just as well use normal 
> deferred worker? RCU may have a benefit of being relaxed in timing ie we 
> don't care it happens immediately, but also don't want to put some made 
> up time period against it. So it's all about natural batching only at 
> this point?

At this moment, to fix up the current bug and to allow i915_active to be
struct_mutex-less, we need to defer the i915_vm_release and
gen8_ppgtt_release to process context. Hence using the worker callback
and not the regular softirq-context rcu callback.
-Chris