drm/i915: Keep the mm.bound_list in rough LRU order
diff mbox

Message ID 1437989186-5644-1-git-send-email-chris@chris-wilson.co.uk
State New
Headers show

Commit Message

Chris Wilson July 27, 2015, 9:26 a.m. UTC
When we shrink our working sets, we want to avoid stealing pages from
objects that likely to be reused in the near future. We first look at
inactive objects before processing active objects - but what about a
recently active object that is about to be used again. That object's
position in the bound_list is ordered by the time of binding, not the
time of last use, so the most recently used inactive object could well
be at the head of the shrink list. To compensate, give the object a bump
to MRU when it becomes inactive (thus transitioning to the end of the
first pass in shrink lists). Conversely, bumping on inactive makes
bumping on active useless, since when we do have to reap from the active
working set, everything is going to become inactive very quickly and the
order pretty much random - just hope for the best at that point, as once
we start stalling on active objects, we can hope that the rebinding
neatly orders vital objects.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_gem.c | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Daniel Vetter July 28, 2015, 11:31 a.m. UTC | #1
On Mon, Jul 27, 2015 at 10:26:26AM +0100, Chris Wilson wrote:
> When we shrink our working sets, we want to avoid stealing pages from
> objects that likely to be reused in the near future. We first look at
> inactive objects before processing active objects - but what about a
> recently active object that is about to be used again. That object's
> position in the bound_list is ordered by the time of binding, not the
> time of last use, so the most recently used inactive object could well
> be at the head of the shrink list. To compensate, give the object a bump
> to MRU when it becomes inactive (thus transitioning to the end of the
> first pass in shrink lists). Conversely, bumping on inactive makes
> bumping on active useless, since when we do have to reap from the active
> working set, everything is going to become inactive very quickly and the
> order pretty much random - just hope for the best at that point, as once
> we start stalling on active objects, we can hope that the rebinding
> neatly orders vital objects.
> 
> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>

Queued for -next, thanks for the patch and let's see what happens. We have
a history of innocent list order changes uncovering interesting bugs ...
-Daniel

Patch
diff mbox

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d3016f37cd4d..01848057611c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2372,6 +2372,13 @@  i915_gem_object_retire__read(struct drm_i915_gem_request_node *node,
 	if (I915_BO_IS_ACTIVE(obj))
 		return;
 
+	/* Bump our place on the bound list to keep it roughly in LRU order
+	 * so that we don't steal from recently used but inactive objects
+	 * (unless we are forced to ofc!)
+	 */
+	list_move_tail(&obj->global_list,
+		       &to_i915(obj->base.dev)->mm.bound_list);
+
 	if (obj->active_reference) {
 		obj->active_reference = false;
 		drm_gem_object_unreference(&obj->base);