Re: [PATCH 01/28] drm/i915: Move fence register tracking from i915->mm to ggtt

[Mika Kuoppala <mika.kuoppala@linux.intel.com>]

Chris Wilson <chris@chris-wilson.co.uk> writes:

> Quoting Mika Kuoppala (2019-06-10 10:46:43)
>> Chris Wilson <chris@chris-wilson.co.uk> writes:
>> >  static int i915_gem_fence_regs_info(struct seq_file *m, void *data)
>> >  {
>> > -     struct drm_i915_private *dev_priv = node_to_i915(m->private);
>> > -     struct drm_device *dev = &dev_priv->drm;
>> > -     int i, ret;
>> > +     struct drm_i915_private *i915 = node_to_i915(m->private);
>> > +     unsigned int i;
>> >  
>> > -     ret = mutex_lock_interruptible(&dev->struct_mutex);
>> > -     if (ret)
>> > -             return ret;
>> > +     seq_printf(m, "Total fences = %d\n", i915->ggtt.num_fences);
>> >  
>> > -     seq_printf(m, "Total fences = %d\n", dev_priv->num_fence_regs);
>> > -     for (i = 0; i < dev_priv->num_fence_regs; i++) {
>> > -             struct i915_vma *vma = dev_priv->fence_regs[i].vma;
>> > +     rcu_read_lock();
>> 
>> This does not seem to be for reset. So it must be for keeping
>> the object alive.
>
> Correct.
>  
>> What guarantees that the obj is kept alive over this rcu
>> lock?
>
> That the object is RCU protected. :-p
>
> It is a relatively simple one (it used to be manual RCU barriers),
> i915_gem_free_object() uses call_rcu() to only queue the object for
> freeing after an RCU grace period has elapsed.

I was grepping for synchronize_rcu and ended up confused. This
is what I was looking for.

Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx