All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH 09/20] drm/i915: Remove walk over obj->vma_list for the shrinker
Date: Wed, 23 Aug 2017 10:15:03 +0100	[thread overview]
Message-ID: <20170823091514.29354-10-chris@chris-wilson.co.uk> (raw)
In-Reply-To: <20170823091514.29354-1-chris@chris-wilson.co.uk>

In the next patch, we want to reduce the lock coverage within the
shrinker, and one of the dangerous walks we have is over obj->vma_list.
We are only walking the obj->vma_list in order to check whether it has
been permanently pinned by HW access, typically via use on the scanout.
But we have a couple of other long term pins, the context objects for
which we currently have to check the individual vma pin_count. If we
instead mark these using obj->pin_display, we can forgo the dangerous
and sometimes slow list iteration.

v2: Rearrange code to try and avoid confusion from false associations
due to arrangement of whitespace along with rebasing on obj->pin_global.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 27 +++++++--------------------
 drivers/gpu/drm/i915/intel_lrc.c         |  2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c  |  7 ++++++-
 3 files changed, 15 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 80caeadb9d34..efb201911cdb 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -71,25 +71,6 @@ static void shrinker_unlock(struct drm_i915_private *dev_priv, bool unlock)
 	mutex_unlock(&dev_priv->drm.struct_mutex);
 }
 
-static bool any_vma_pinned(struct drm_i915_gem_object *obj)
-{
-	struct i915_vma *vma;
-
-	list_for_each_entry(vma, &obj->vma_list, obj_link) {
-		/* Only GGTT vma may be permanently pinned, and are always
-		 * at the start of the list. We can stop hunting as soon
-		 * as we see a ppGTT vma.
-		 */
-		if (!i915_vma_is_ggtt(vma))
-			break;
-
-		if (i915_vma_is_pinned(vma))
-			return true;
-	}
-
-	return false;
-}
-
 static bool swap_available(void)
 {
 	return get_nr_swap_pages() > 0;
@@ -115,7 +96,13 @@ static bool can_release_pages(struct drm_i915_gem_object *obj)
 	if (atomic_read(&obj->mm.pages_pin_count) > obj->bind_count)
 		return false;
 
-	if (any_vma_pinned(obj))
+	/* If any vma are "permanently" pinned, it will prevent us from
+	 * reclaiming the obj->mm.pages. We only allow scanout objects to claim
+	 * a permanent pin, along with a few others like the context objects.
+	 * To simplify the scan, and to avoid walking the list of vma under the
+	 * object, we just check the count of its permanently pinned.
+	 */
+	if (obj->pin_global)
 		return false;
 
 	/* We can only return physical pages to the system if we can either
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d89e1b8e1cc5..68deede1f666 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -866,6 +866,7 @@ execlists_context_pin(struct intel_engine_cs *engine,
 		i915_ggtt_offset(ce->ring->vma);
 
 	ce->state->obj->mm.dirty = true;
+	ce->state->obj->pin_global++;
 
 	i915_gem_context_get(ctx);
 out:
@@ -893,6 +894,7 @@ static void execlists_context_unpin(struct intel_engine_cs *engine,
 
 	intel_ring_unpin(ce->ring);
 
+	ce->state->obj->pin_global--;
 	i915_gem_object_unpin_map(ce->state->obj);
 	i915_vma_unpin(ce->state);
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index cdf084ef5aae..c3b1f10aa98a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1321,6 +1321,7 @@ int intel_ring_pin(struct intel_ring *ring,
 	if (IS_ERR(addr))
 		goto err;
 
+	vma->obj->pin_global++;
 	ring->vaddr = addr;
 	return 0;
 
@@ -1352,6 +1353,7 @@ void intel_ring_unpin(struct intel_ring *ring)
 		i915_gem_object_unpin_map(ring->vma->obj);
 	ring->vaddr = NULL;
 
+	ring->vma->obj->pin_global--;
 	i915_vma_unpin(ring->vma);
 }
 
@@ -1515,6 +1517,7 @@ intel_ring_context_pin(struct intel_engine_cs *engine,
 		if (ret)
 			goto err;
 
+		ce->state->obj->pin_global++;
 		ce->state->obj->mm.dirty = true;
 	}
 
@@ -1550,8 +1553,10 @@ static void intel_ring_context_unpin(struct intel_engine_cs *engine,
 	if (--ce->pin_count)
 		return;
 
-	if (ce->state)
+	if (ce->state) {
+		ce->state->obj->pin_global--;
 		i915_vma_unpin(ce->state);
+	}
 
 	i915_gem_context_put(ctx);
 }
-- 
2.14.1

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

  parent reply	other threads:[~2017-08-23  9:15 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-23  9:14 The bunch of mm patches in the queue, mostly for shard testing Chris Wilson
2017-08-23  9:14 ` [PATCH 01/20] drm/i915: "Race-to-idle" on switching to the kernel context Chris Wilson
2017-08-23  9:14 ` [PATCH 02/20] drm/i915: Assert the context is not closed on object-close Chris Wilson
2017-08-23 16:50   ` Michał Winiarski
2017-08-23 16:57     ` Chris Wilson
2017-08-23  9:14 ` [PATCH 03/20] drm/i915: Assert that the handle->vma lut is empty on object close Chris Wilson
2017-08-23 16:54   ` Michał Winiarski
2017-08-23  9:14 ` [PATCH 04/20] drm/i915: Ignore duplicate VMA stored within the per-object handle LUT Chris Wilson
2017-08-23 17:40   ` Michał Winiarski
2017-08-23  9:14 ` [PATCH 05/20] drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects Chris Wilson
2017-08-23  9:15 ` [PATCH 06/20] drm/i915: Refactor testing obj->mm.pages Chris Wilson
2017-08-23  9:15 ` [PATCH 07/20] drm/i915: Rename obj->pin_display to obj->pin_global Chris Wilson
2017-08-23  9:15 ` [PATCH 08/20] drm/i915: Drop debugfs/i915_gem_pin_display Chris Wilson
2017-08-23  9:15 ` Chris Wilson [this message]
2017-08-23  9:15 ` [PATCH 10/20] drm/i915: Move dev_priv->mm.[un]bound_list to its own lock Chris Wilson
2017-08-23  9:15 ` [PATCH 11/20] drm/i915: Set our shrinker->batch to 4096 (~16MiB) Chris Wilson
2017-08-23  9:15 ` [PATCH 12/20] drm/i915: Trim struct_mutex hold duration for i915_gem_free_objects Chris Wilson
2017-08-23  9:15 ` [PATCH 13/20] drm/i915: Start writeback from the shrinker Chris Wilson
2017-08-23  9:15 ` [PATCH 14/20] drm/i915: Discard VMA lut handles upon purging the object Chris Wilson
2017-08-23  9:15 ` [PATCH 15/20] drm/i915: Only free the oldest stale object before a fresh allocation Chris Wilson
2017-08-23  9:15 ` [PATCH 16/20] mm: Track actual nr_scanned during shrink_slab() Chris Wilson
2017-08-23  9:15 ` [PATCH 17/20] drm/i915: Wire up shrinkctl->nr_scanned Chris Wilson
2017-08-23  9:15 ` [PATCH 18/20] mm, drm/i915: Mark pinned shmemfs pages as unevictable Chris Wilson
2017-08-23  9:15 ` [PATCH 19/20] shmem: Support for registration of driver/file owner specific ops Chris Wilson
2017-08-23  9:15 ` [PATCH 20/20] drm/i915: Make GPU pages movable Chris Wilson
2017-08-23  9:36 ` ✗ Fi.CI.BAT: failure for series starting with [01/20] drm/i915: "Race-to-idle" on switching to the kernel context Patchwork
2017-08-25 10:41 ` Patchwork

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=20170823091514.29354-10-chris@chris-wilson.co.uk \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.