All of lore.kernel.org
 help / color / mirror / Atom feed
* [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects
@ 2020-04-24 15:24 Chris Wilson
  2020-04-24 16:01 ` Janusz Krzysztofik
                   ` (4 more replies)
  0 siblings, 5 replies; 13+ messages in thread
From: Chris Wilson @ 2020-04-24 15:24 UTC (permalink / raw)
  To: intel-gfx; +Cc: Chris Wilson

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);
 
-- 
2.20.1

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

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects
  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
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 13+ messages in thread
From: Janusz Krzysztofik @ 2020-04-24 16:01 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx

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).

Thanks for taking car of this issue.  Your solution looks very
promising to me at a first glance, but let me review it more thoroughly
and test it before I'm able to respond with an ack or R-b.

Thanks,
Janusz

> 
> 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);
>  

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Lazily acquire the device wakeref for freeing objects
  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 ` Patchwork
  2020-04-24 18:42 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2020-04-24 16:12 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/gem: Lazily acquire the device wakeref for freeing objects
URL   : https://patchwork.freedesktop.org/series/76440/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8360 -> Patchwork_17453
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/index.html

Known issues
------------

  Here are the changes found in Patchwork_17453 that come from known issues:

### IGT changes ###

#### Possible fixes ####

  * igt@i915_selftest@live@execlists:
    - fi-cml-s:           [INCOMPLETE][1] -> [PASS][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/fi-cml-s/igt@i915_selftest@live@execlists.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/fi-cml-s/igt@i915_selftest@live@execlists.html

  * igt@i915_selftest@live@gt_timelines:
    - fi-bwr-2160:        [INCOMPLETE][3] ([i915#489]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/fi-bwr-2160/igt@i915_selftest@live@gt_timelines.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/fi-bwr-2160/igt@i915_selftest@live@gt_timelines.html

  
  [i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489


Participating hosts (48 -> 43)
------------------------------

  Additional (1): fi-kbl-7500u 
  Missing    (6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8360 -> Patchwork_17453

  CI-20190529: 20190529
  CI_DRM_8360: 034e1ba4afede6e10ef50596f891b7ff85f4ae22 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5610: 71fed15724898a8f914666093352a964b70a62fc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17453: 06a8555045e20cde4126faf363592728f2a2d69f @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

06a8555045e2 drm/i915/gem: Lazily acquire the device wakeref for freeing objects

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Lazily acquire the device wakeref for freeing objects
  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 ` Patchwork
  2020-04-28  9:53 ` [Intel-gfx] [PATCH] " Janusz Krzysztofik
  2020-04-28 12:45 ` Janusz Krzysztofik
  4 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2020-04-24 18:42 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/gem: Lazily acquire the device wakeref for freeing objects
URL   : https://patchwork.freedesktop.org/series/76440/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8360_full -> Patchwork_17453_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Known issues
------------

  Here are the changes found in Patchwork_17453_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_eio@in-flight-suspend:
    - shard-apl:          [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-apl6/igt@gem_eio@in-flight-suspend.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-apl1/igt@gem_eio@in-flight-suspend.html

  * igt@i915_pm_dc@dc6-psr:
    - shard-iclb:         [PASS][3] -> [FAIL][4] ([i915#454])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-iclb3/igt@i915_pm_dc@dc6-psr.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-iclb8/igt@i915_pm_dc@dc6-psr.html

  * igt@i915_suspend@sysfs-reader:
    - shard-kbl:          [PASS][5] -> [INCOMPLETE][6] ([CI#80] / [i915#155])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-kbl6/igt@i915_suspend@sysfs-reader.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-kbl1/igt@i915_suspend@sysfs-reader.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
    - shard-kbl:          [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +3 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-kbl7/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-kbl7/igt@kms_cursor_crc@pipe-a-cursor-suspend.html

  * igt@kms_draw_crc@draw-method-rgb565-blt-untiled:
    - shard-glk:          [PASS][9] -> [FAIL][10] ([i915#52] / [i915#54])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-glk8/igt@kms_draw_crc@draw-method-rgb565-blt-untiled.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-glk2/igt@kms_draw_crc@draw-method-rgb565-blt-untiled.html

  * igt@kms_hdr@bpc-switch:
    - shard-skl:          [PASS][11] -> [FAIL][12] ([i915#1188])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-skl7/igt@kms_hdr@bpc-switch.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-skl8/igt@kms_hdr@bpc-switch.html

  * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
    - shard-kbl:          [PASS][13] -> [FAIL][14] ([i915#53] / [i915#93] / [i915#95])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-kbl1/igt@kms_pipe_crc_basic@hang-read-crc-pipe-a.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-kbl1/igt@kms_pipe_crc_basic@hang-read-crc-pipe-a.html
    - shard-apl:          [PASS][15] -> [FAIL][16] ([i915#53] / [i915#95])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-apl7/igt@kms_pipe_crc_basic@hang-read-crc-pipe-a.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-apl3/igt@kms_pipe_crc_basic@hang-read-crc-pipe-a.html

  * igt@kms_psr@psr2_cursor_plane_onoff:
    - shard-iclb:         [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-iclb3/igt@kms_psr@psr2_cursor_plane_onoff.html

  
#### Possible fixes ####

  * igt@kms_color@pipe-a-ctm-green-to-red:
    - shard-skl:          [FAIL][19] ([i915#129]) -> [PASS][20]
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-skl6/igt@kms_color@pipe-a-ctm-green-to-red.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-skl3/igt@kms_color@pipe-a-ctm-green-to-red.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
    - shard-skl:          [FAIL][21] ([i915#54]) -> [PASS][22] +1 similar issue
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-skl6/igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-skl3/igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen.html

  * {igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1}:
    - shard-skl:          [FAIL][23] ([i915#79]) -> [PASS][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-skl9/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html

  * {igt@kms_flip@flip-vs-suspend-interruptible@a-dp1}:
    - shard-kbl:          [DMESG-WARN][25] ([i915#180]) -> [PASS][26] +2 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-kbl1/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-kbl1/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html

  * {igt@kms_flip@flip-vs-suspend-interruptible@b-vga1}:
    - shard-snb:          [INCOMPLETE][27] ([i915#82]) -> [PASS][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-snb1/igt@kms_flip@flip-vs-suspend-interruptible@b-vga1.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-snb4/igt@kms_flip@flip-vs-suspend-interruptible@b-vga1.html

  * {igt@kms_flip@flip-vs-suspend@b-hdmi-a1}:
    - shard-hsw:          [INCOMPLETE][29] ([i915#61]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-hsw4/igt@kms_flip@flip-vs-suspend@b-hdmi-a1.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-hsw2/igt@kms_flip@flip-vs-suspend@b-hdmi-a1.html

  * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-pwrite:
    - shard-skl:          [FAIL][31] ([i915#49]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-skl6/igt@kms_frontbuffer_tracking@psr-rgb101010-draw-pwrite.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-skl3/igt@kms_frontbuffer_tracking@psr-rgb101010-draw-pwrite.html

  * igt@kms_hdr@bpc-switch-suspend:
    - shard-skl:          [FAIL][33] ([i915#1188]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-skl6/igt@kms_hdr@bpc-switch-suspend.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-skl3/igt@kms_hdr@bpc-switch-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
    - shard-apl:          [DMESG-WARN][35] ([i915#180]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-apl3/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-apl7/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
    - shard-skl:          [INCOMPLETE][37] ([i915#69]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-skl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-skl2/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [FAIL][39] ([fdo#108145] / [i915#265]) -> [PASS][40] +3 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-skl4/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-skl6/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  * igt@kms_psr@psr2_cursor_blt:
    - shard-iclb:         [SKIP][41] ([fdo#109441]) -> [PASS][42] +3 similar issues
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-iclb3/igt@kms_psr@psr2_cursor_blt.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html

  * igt@kms_setmode@basic:
    - shard-apl:          [FAIL][43] ([i915#31]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-apl6/igt@kms_setmode@basic.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-apl1/igt@kms_setmode@basic.html

  * {igt@perf@polling-parameterized}:
    - shard-hsw:          [FAIL][45] ([i915#1542]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-hsw6/igt@perf@polling-parameterized.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-hsw4/igt@perf@polling-parameterized.html

  
#### Warnings ####

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-apl:          [DMESG-FAIL][47] ([i915#180] / [i915#95]) -> [FAIL][48] ([i915#95])
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-apl6/igt@kms_fbcon_fbt@fbc-suspend.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-apl1/igt@kms_fbcon_fbt@fbc-suspend.html
    - shard-kbl:          [FAIL][49] ([i915#93] / [i915#95]) -> [DMESG-FAIL][50] ([i915#180] / [i915#95])
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8360/shard-kbl4/igt@kms_fbcon_fbt@fbc-suspend.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/shard-kbl7/igt@kms_fbcon_fbt@fbc-suspend.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
  [i915#129]: https://gitlab.freedesktop.org/drm/intel/issues/129
  [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
  [i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
  [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
  [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
  [i915#52]: https://gitlab.freedesktop.org/drm/intel/issues/52
  [i915#53]: https://gitlab.freedesktop.org/drm/intel/issues/53
  [i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
  [i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
  [i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
  [i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
  [i915#82]: https://gitlab.freedesktop.org/drm/intel/issues/82
  [i915#93]: https://gitlab.freedesktop.org/drm/intel/issues/93
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (10 -> 10)
------------------------------

  No changes in participating hosts


Build changes
-------------

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8360 -> Patchwork_17453

  CI-20190529: 20190529
  CI_DRM_8360: 034e1ba4afede6e10ef50596f891b7ff85f4ae22 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5610: 71fed15724898a8f914666093352a964b70a62fc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17453: 06a8555045e20cde4126faf363592728f2a2d69f @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17453/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects
  2020-04-24 15:24 [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects Chris Wilson
                   ` (2 preceding siblings ...)
  2020-04-24 18:42 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
@ 2020-04-28  9:53 ` Janusz Krzysztofik
  2020-04-28  9:55   ` Chris Wilson
  2020-04-28 12:45 ` Janusz Krzysztofik
  4 siblings, 1 reply; 13+ messages in thread
From: Janusz Krzysztofik @ 2020-04-28  9:53 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx

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.

Makes sense.
> 
> 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).

I'm still not sure if we really don't have to care about removing GGTT
related mappings in any possible scenario, e.g., device unplug and re-
plug vs. driver unbind and rebind to the same device still in place.   
Trybot results look promising but as I said, I'm not sure so let me
raise that point.

Thanks,
Janusz

> 
> 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);
>  

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects
  2020-04-28  9:53 ` [Intel-gfx] [PATCH] " Janusz Krzysztofik
@ 2020-04-28  9:55   ` Chris Wilson
  0 siblings, 0 replies; 13+ messages in thread
From: Chris Wilson @ 2020-04-28  9:55 UTC (permalink / raw)
  To: Janusz Krzysztofik, intel-gfx

Quoting Janusz Krzysztofik (2020-04-28 10:53:38)
> 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.
> 
> Makes sense.
> > 
> > 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).
> 
> I'm still not sure if we really don't have to care about removing GGTT
> related mappings in any possible scenario, e.g., device unplug and re-
> plug vs. driver unbind and rebind to the same device still in place.   
> Trybot results look promising but as I said, I'm not sure so let me
> raise that point.

We control the contents of the GGTT and rewrite it upon takeover. It's
*our* translation table!
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects
  2020-04-24 15:24 [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects Chris Wilson
                   ` (3 preceding siblings ...)
  2020-04-28  9:53 ` [Intel-gfx] [PATCH] " Janusz Krzysztofik
@ 2020-04-28 12:45 ` Janusz Krzysztofik
  2020-04-28 12:59   ` Chris Wilson
  4 siblings, 1 reply; 13+ messages in thread
From: Janusz Krzysztofik @ 2020-04-28 12:45 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx

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)?

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?

Thanks,
Janusz

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects
  2020-04-28 12:45 ` Janusz Krzysztofik
@ 2020-04-28 12:59   ` Chris Wilson
  2020-04-28 14:35     ` Janusz Krzysztofik
  0 siblings, 1 reply; 13+ messages in thread
From: Chris Wilson @ 2020-04-28 12:59 UTC (permalink / raw)
  To: Janusz Krzysztofik, intel-gfx

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects
  2020-04-28 12:59   ` Chris Wilson
@ 2020-04-28 14:35     ` Janusz Krzysztofik
  2020-04-28 14:48       ` Chris Wilson
  0 siblings, 1 reply; 13+ messages in thread
From: Janusz Krzysztofik @ 2020-04-28 14:35 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx

On Tue, 2020-04-28 at 13:59 +0100, Chris Wilson wrote:
> 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.
>         */

For me, that still doesn't explain why we are free to request PPGTT
lock subclass, not the one dedicated to GGTT as the comment suggests I
believe, when locking GGTT vm only because that GGTT vm is closed.

> 
> > 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.

As I haven't found this explanation sufficiently clear for me, I've had
a closer look as my homework.  As a result, I think the answer why this
may be safe can be found in commits b6422694c585 ("drm/i915/gt: Only
wait for register chipset flush if active") and 0d86ee35097a
("drm/i915/gt: Make fence revocation unequivocal").

Thanks,
Janusz

> -Chris

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects
  2020-04-28 14:35     ` Janusz Krzysztofik
@ 2020-04-28 14:48       ` Chris Wilson
  2020-04-28 15:30         ` Janusz Krzysztofik
  0 siblings, 1 reply; 13+ messages in thread
From: Chris Wilson @ 2020-04-28 14:48 UTC (permalink / raw)
  To: Janusz Krzysztofik, intel-gfx

Quoting Janusz Krzysztofik (2020-04-28 15:35:03)
> On Tue, 2020-04-28 at 13:59 +0100, Chris Wilson wrote:
> > 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.
> >         */
> 
> For me, that still doesn't explain why we are free to request PPGTT
> lock subclass, not the one dedicated to GGTT as the comment suggests I
> believe, when locking GGTT vm only because that GGTT vm is closed.

The choice of subclass is not affected by i915_vm_is_closed. It is based
solely on whether to not the vma was only used as PIN_USER.

> > > 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.
> 
> As I haven't found this explanation sufficiently clear for me, I've had
> a closer look as my homework.  As a result, I think the answer why this
> may be safe can be found in commits b6422694c585 ("drm/i915/gt: Only
> wait for register chipset flush if active") and 0d86ee35097a
> ("drm/i915/gt: Make fence revocation unequivocal").

No. We were always free to ignore discarding the fence if not awake.
This wakeref is only about the GGTT unbind as we pulled the wakeref from
inside the ggtt_unbind to here to avoid a lock inversion via the
vm->mutex + shrinker.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects
  2020-04-28 14:48       ` Chris Wilson
@ 2020-04-28 15:30         ` Janusz Krzysztofik
  0 siblings, 0 replies; 13+ messages in thread
From: Janusz Krzysztofik @ 2020-04-28 15:30 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx

On Tue, 2020-04-28 at 15:48 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-04-28 15:35:03)
> > On Tue, 2020-04-28 at 13:59 +0100, Chris Wilson wrote:
> > > 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.
> > >         */
> > 
> > For me, that still doesn't explain why we are free to request PPGTT
> > lock subclass, not the one dedicated to GGTT as the comment suggests I
> > believe, when locking GGTT vm only because that GGTT vm is closed.
> 
> The choice of subclass is not affected by i915_vm_is_closed. It is based
> solely on whether to not the vma was only used as PIN_USER.

That was true before the change, now the subclass argument also depends
on vma->vm->open:

-	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);

	err = mutex_lock_interruptible_nested(&vma->vm->mutex, !wakeref);

> 
> > > > 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.
> > 
> > As I haven't found this explanation sufficiently clear for me, I've had
> > a closer look as my homework.  As a result, I think the answer why this
> > may be safe can be found in commits b6422694c585 ("drm/i915/gt: Only
> > wait for register chipset flush if active") and 0d86ee35097a
> > ("drm/i915/gt: Make fence revocation unequivocal").
> 
> No. We were always free to ignore discarding the fence if not awake.
> This wakeref is only about the GGTT unbind as we pulled the wakeref from
> inside the ggtt_unbind to here to avoid a lock inversion via the
> vm->mutex + shrinker.

OK, but anyway, looking at those changes, especially the first one, I
can see we find hardware operations we are going to perform as safe
even if the device is not powered on.

Thanks,
Janusz

> -Chris

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects
  2020-05-03 17:15 Chris Wilson
@ 2020-05-04  7:44 ` Janusz Krzysztofik
  0 siblings, 0 replies; 13+ messages in thread
From: Janusz Krzysztofik @ 2020-05-04  7:44 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx

On Sun, 2020-05-03 at 18:15 +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.
> 
> 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_object.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> 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)

Reviewed-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>

Thanks,
Janusz

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Intel-gfx] [PATCH] drm/i915/gem: Lazily acquire the device wakeref for freeing objects
@ 2020-05-03 17:15 Chris Wilson
  2020-05-04  7:44 ` Janusz Krzysztofik
  0 siblings, 1 reply; 13+ messages in thread
From: Chris Wilson @ 2020-05-03 17:15 UTC (permalink / raw)
  To: intel-gfx; +Cc: Chris Wilson

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.

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_object.c | 3 ---
 1 file changed, 3 deletions(-)

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)
-- 
2.20.1

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

^ permalink raw reply related	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2020-05-04  7:44 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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.