All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects
Date: Tue, 28 Apr 2020 13:59:42 +0100	[thread overview]
Message-ID: <158807878202.24122.7735670150825044322@build.alporthouse.com> (raw)
In-Reply-To: <64c6797e1031f3f9da8b29cce8553b059b788a31.camel@linux.intel.com>

Quoting Janusz Krzysztofik (2020-04-28 13:45:13)
> Hi Chris,
> 
> On Fri, 2020-04-24 at 16:24 +0100, Chris Wilson wrote:
> > We only need the device wakeref on freeing the objects if we have to
> > unbind the object from the global GTT, or otherwise update device
> > information. If the objects are clean, we never need the wakeref, so
> > avoid taking until required.
> > 
> > For this to be effective in preventing us from waking the device after
> > it is unbind, we also need to mark the GGTT as closed on device removal.
> > The GGTT will be rebuilt from scratch the next time we need to open it
> > (on binding a new device).
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_mman.c   | 3 +++
> >  drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 ---
> >  drivers/gpu/drm/i915/gt/intel_ggtt.c       | 9 +++++++--
> >  drivers/gpu/drm/i915/gt/intel_gtt.h        | 1 +
> >  drivers/gpu/drm/i915/i915_drv.c            | 1 +
> >  drivers/gpu/drm/i915/i915_vma.c            | 3 ++-
> >  6 files changed, 14 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > index b39c24dae64e..c6cead6f2b3e 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > @@ -421,6 +421,9 @@ static void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj)
> >       struct drm_i915_private *i915 = to_i915(obj->base.dev);
> >       intel_wakeref_t wakeref;
> >  
> > +     if (!atomic_read(&i915->ggtt.vm.open))
> > +             return;
> > +
> >       /*
> >        * Serialisation between user GTT access and our code depends upon
> >        * revoking the CPU's PTE whilst the mutex is held. The next user
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index 9d1d0131f7c2..99356c00c19e 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -162,9 +162,7 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915,
> >                                   struct llist_node *freed)
> >  {
> >       struct drm_i915_gem_object *obj, *on;
> > -     intel_wakeref_t wakeref;
> >  
> > -     wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> >       llist_for_each_entry_safe(obj, on, freed, freed) {
> >               struct i915_mmap_offset *mmo, *mn;
> >  
> > @@ -224,7 +222,6 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915,
> >               call_rcu(&obj->rcu, __i915_gem_free_object_rcu);
> >               cond_resched();
> >       }
> > -     intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> >  }
> >  
> >  void i915_gem_flush_free_objects(struct drm_i915_private *i915)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > index 66165b10256e..b65545182ef5 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > @@ -681,8 +681,6 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
> >  {
> >       struct i915_vma *vma, *vn;
> >  
> > -     atomic_set(&ggtt->vm.open, 0);
> > -
> >       rcu_barrier(); /* flush the RCU'ed__i915_vm_release */
> >       flush_workqueue(ggtt->vm.i915->wq);
> >  
> > @@ -709,6 +707,13 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
> >               io_mapping_fini(&ggtt->iomap);
> >  }
> >  
> > +void i915_ggtt_driver_remove(struct drm_i915_private *i915)
> > +{
> > +     struct i915_ggtt *ggtt = &i915->ggtt;
> > +
> > +     atomic_set(&ggtt->vm.open, 0);
> > +}
> > +
> >  /**
> >   * i915_ggtt_driver_release - Clean up GGTT hardware initialization
> >   * @i915: i915 device
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
> > index d93ebdf3fa0e..f140ce5c171a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> > @@ -501,6 +501,7 @@ int i915_ggtt_enable_hw(struct drm_i915_private *i915);
> >  void i915_ggtt_enable_guc(struct i915_ggtt *ggtt);
> >  void i915_ggtt_disable_guc(struct i915_ggtt *ggtt);
> >  int i915_init_ggtt(struct drm_i915_private *i915);
> > +void i915_ggtt_driver_remove(struct drm_i915_private *i915);
> >  void i915_ggtt_driver_release(struct drm_i915_private *i915);
> >  
> >  static inline bool i915_ggtt_has_aperture(const struct i915_ggtt *ggtt)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> > index 2d62efd9316f..bdf97a1cb7cc 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -768,6 +768,7 @@ static void i915_driver_hw_remove(struct drm_i915_private *dev_priv)
> >  
> >       i915_perf_fini(dev_priv);
> >  
> > +     i915_ggtt_driver_remove(dev_priv);
> >       if (pdev->msi_enabled)
> >               pci_disable_msi(pdev);
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> > index fc14ebf9a0b7..6fe56ad2a542 100644
> > --- a/drivers/gpu/drm/i915/i915_vma.c
> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > @@ -1319,7 +1319,8 @@ int i915_vma_unbind(struct i915_vma *vma)
> >               return -EAGAIN;
> >       }
> >  
> > -     if (i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND))
> > +     if (i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND) &&
> > +         atomic_read(&vma->vm->open))
> >               /* XXX not always required: nop_clear_range */
> >               wakeref = intel_runtime_pm_get(&vm->i915->runtime_pm);
> >  
> 
> Can you please explain why you think it is OK to call
> mutex_lock_interruptible_nested(&closed_GGTT->mutex, PPGTT_subclass)?

That should be explained in the comments

       /*
        * Differentiate between user/kernel vma inside the aliasing-ppgtt.
        *
        * We conflate the Global GTT with the user's vma when using the
        * aliasing-ppgtt, but it is still vitally important to try and
        * keep the use cases distinct. For example, userptr objects are
        * not allowed inside the Global GTT as that will cause lock
        * inversions when we have to evict them the mmu_notifier callbacks -
        * but they are allowed to be part of the user ppGTT which can never
        * be mapped. As such we try to give the distinct users of the same
        * mutex, distinct lockclasses [equivalent to how we keep i915_ggtt
        * and i915_ppgtt separate].
        *
        * NB this may cause us to mask real lock inversions -- while the
        * code is safe today, lockdep may not be able to spot future
        * transgressions.
        */

> Can you please also explain why you think it is safe to call
> __i915_vma_unbind(vma_bound_to_GGTT) even if wakeref is not taken?

Because it has been closed, and only inside strictly serial code.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-04-28 12:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24 15:24 [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects Chris Wilson
2020-04-24 16:01 ` Janusz Krzysztofik
2020-04-24 16:12 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2020-04-24 18:42 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-04-28  9:53 ` [Intel-gfx] [PATCH] " Janusz Krzysztofik
2020-04-28  9:55   ` Chris Wilson
2020-04-28 12:45 ` Janusz Krzysztofik
2020-04-28 12:59   ` Chris Wilson [this message]
2020-04-28 14:35     ` Janusz Krzysztofik
2020-04-28 14:48       ` Chris Wilson
2020-04-28 15:30         ` Janusz Krzysztofik
2020-05-03 17:15 Chris Wilson
2020-05-04  7:44 ` Janusz Krzysztofik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=158807878202.24122.7735670150825044322@build.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=janusz.krzysztofik@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.