On 15/01/2018 21:24, Chris Wilson wrote:
When we finally decide the gpu is idle, that is a good time to shrink
our kmem_caches.
Signed-off-by: Chris Wilson <[email protected]>
---
drivers/gpu/drm/i915/i915_gem.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a8840a514377..8547f5214599 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4709,6 +4709,21 @@ i915_gem_retire_work_handler(struct work_struct *work)
}
}
+static void shrink_caches(struct drm_i915_private *i915)
+{
+ /*
+ * kmem_cache_shrink() discards empty slabs and reorders partially
+ * filled slabs to prioritise allocating from the mostly full slabs,
+ * with the aim of reducing fragmentation.
+ */
This makes it sound like it would be a very good thing in general.
+ kmem_cache_shrink(i915->priorities);
+ kmem_cache_shrink(i915->dependencies);
+ kmem_cache_shrink(i915->requests);
+ kmem_cache_shrink(i915->luts);
+ kmem_cache_shrink(i915->vmas);
+ kmem_cache_shrink(i915->objects);
+}
+
static inline bool
new_requests_since_last_retire(const struct drm_i915_private *i915)
{
@@ -4796,6 +4811,13 @@ i915_gem_idle_work_handler(struct work_struct *work)
GEM_BUG_ON(!dev_priv->gt.awake);
i915_queue_hangcheck(dev_priv);
}
+
+ rcu_barrier();
Ugh, more sprinkled around complexity we add the more difficult it
becomes to maintain the code base for mere mortals. At the very minimum
a comment is needed here.
What about activity other than requests? Like active mmap_gtt, that
might at least create busyness on the vma and object caches and is not
correlated to idle work handler firing.
Regards,
Tvrtko
+
+ if (!new_requests_since_last_retire(dev_priv)) {
+ __i915_gem_free_work(&dev_priv->mm.free_work);
+ shrink_caches(dev_priv);
+ }
}
int i915_gem_suspend(struct drm_i915_private *dev_priv)
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
