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

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

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@intel.com>

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx