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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
