On 19/06/2019 15:56, Chris Wilson wrote:
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.
It's fine by me, I just wanted for some reassurances about future plans. :)
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
