[Intel-gfx] [PATCH 1/7] drm/i915/gtt: Defer address space cleanup to an RCU worker
Chris Wilson
chris at chris-wilson.co.uk
Wed Jun 19 14:56:53 UTC 2019
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
More information about the Intel-gfx
mailing list