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

Chris Wilson chris at chris-wilson.co.uk
Mon Jun 10 10:54:39 UTC 2019


Quoting Mika Kuoppala (2019-06-10 10:46:43)
> Chris Wilson <chris at 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.
-Chris


More information about the Intel-gfx mailing list