All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/4] drm/mm: Reject over-sized allocation requests early
@ 2018-05-13  7:50 Chris Wilson
  2018-05-13  7:50 ` [PATCH 2/4] drm/mm: Add a search-by-address variant to only inspect a single hole Chris Wilson
                   ` (5 more replies)
  0 siblings, 6 replies; 12+ messages in thread
From: Chris Wilson @ 2018-05-13  7:50 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

As we keep an rbtree of available holes sorted by their size, we can
very easily determine if there is any hole large enough that might
satisfy the allocation request. This helps when dealing with a highly
fragmented address space and a request for a search by address.

To cache the largest size, we convert into the cached rbtree variant
which tracks the leftmost node for us. However, currently we sorted into
ascending size order so the leftmost node is the smallest, and so to
make it the largest hole we need to invert our sorting.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 drivers/gpu/drm/drm_mm.c | 82 ++++++++++++++++++++++++++++------------
 include/drm/drm_mm.h     |  2 +-
 2 files changed, 58 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 3166026a1874..7b4ad05fe1c0 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -239,6 +239,32 @@ static void drm_mm_interval_tree_add_node(struct drm_mm_node *hole_node,
 #define HOLE_SIZE(NODE) ((NODE)->hole_size)
 #define HOLE_ADDR(NODE) (__drm_mm_hole_node_start(NODE))
 
+static u64 rb_to_hole_size(struct rb_node *rb)
+{
+	return rb_entry(rb, struct drm_mm_node, rb_hole_size)->hole_size;
+}
+
+static void insert_hole_size(struct rb_root_cached *root,
+			     struct drm_mm_node *node)
+{
+	struct rb_node **link = &root->rb_root.rb_node, *rb = NULL;
+	u64 x = node->hole_size;
+	bool first = true;
+
+	while (*link) {
+		rb = *link;
+		if (x > rb_to_hole_size(rb)) {
+			link = &rb->rb_left;
+		} else {
+			link = &rb->rb_right;
+			first = false;
+		}
+	}
+
+	rb_link_node(&node->rb_hole_size, rb, link);
+	rb_insert_color_cached(&node->rb_hole_size, root, first);
+}
+
 static void add_hole(struct drm_mm_node *node)
 {
 	struct drm_mm *mm = node->mm;
@@ -247,7 +273,7 @@ static void add_hole(struct drm_mm_node *node)
 		__drm_mm_hole_node_end(node) - __drm_mm_hole_node_start(node);
 	DRM_MM_BUG_ON(!drm_mm_hole_follows(node));
 
-	RB_INSERT(mm->holes_size, rb_hole_size, HOLE_SIZE);
+	insert_hole_size(&mm->holes_size, node);
 	RB_INSERT(mm->holes_addr, rb_hole_addr, HOLE_ADDR);
 
 	list_add(&node->hole_stack, &mm->hole_stack);
@@ -258,7 +284,7 @@ static void rm_hole(struct drm_mm_node *node)
 	DRM_MM_BUG_ON(!drm_mm_hole_follows(node));
 
 	list_del(&node->hole_stack);
-	rb_erase(&node->rb_hole_size, &node->mm->holes_size);
+	rb_erase_cached(&node->rb_hole_size, &node->mm->holes_size);
 	rb_erase(&node->rb_hole_addr, &node->mm->holes_addr);
 	node->hole_size = 0;
 
@@ -282,38 +308,39 @@ static inline u64 rb_hole_size(struct rb_node *rb)
 
 static struct drm_mm_node *best_hole(struct drm_mm *mm, u64 size)
 {
-	struct rb_node *best = NULL;
-	struct rb_node **link = &mm->holes_size.rb_node;
+	struct rb_node *rb = mm->holes_size.rb_root.rb_node;
+	struct drm_mm_node *best = NULL;
 
-	while (*link) {
-		struct rb_node *rb = *link;
+	do {
+		struct drm_mm_node *node =
+			rb_entry(rb, struct drm_mm_node, rb_hole_size);
 
-		if (size <= rb_hole_size(rb)) {
-			link = &rb->rb_left;
-			best = rb;
+		if (size <= node->hole_size) {
+			best = node;
+			rb = rb->rb_right;
 		} else {
-			link = &rb->rb_right;
+			rb = rb->rb_left;
 		}
-	}
+	} while (rb);
 
-	return rb_hole_size_to_node(best);
+	return best;
 }
 
 static struct drm_mm_node *find_hole(struct drm_mm *mm, u64 addr)
 {
+	struct rb_node *rb = mm->holes_addr.rb_node;
 	struct drm_mm_node *node = NULL;
-	struct rb_node **link = &mm->holes_addr.rb_node;
 
-	while (*link) {
+	while (rb) {
 		u64 hole_start;
 
-		node = rb_hole_addr_to_node(*link);
+		node = rb_hole_addr_to_node(rb);
 		hole_start = __drm_mm_hole_node_start(node);
 
 		if (addr < hole_start)
-			link = &node->rb_hole_addr.rb_left;
+			rb = node->rb_hole_addr.rb_left;
 		else if (addr > hole_start + node->hole_size)
-			link = &node->rb_hole_addr.rb_right;
+			rb = node->rb_hole_addr.rb_right;
 		else
 			break;
 	}
@@ -326,9 +353,6 @@ first_hole(struct drm_mm *mm,
 	   u64 start, u64 end, u64 size,
 	   enum drm_mm_insert_mode mode)
 {
-	if (RB_EMPTY_ROOT(&mm->holes_size))
-		return NULL;
-
 	switch (mode) {
 	default:
 	case DRM_MM_INSERT_BEST:
@@ -355,7 +379,7 @@ next_hole(struct drm_mm *mm,
 	switch (mode) {
 	default:
 	case DRM_MM_INSERT_BEST:
-		return rb_hole_size_to_node(rb_next(&node->rb_hole_size));
+		return rb_hole_size_to_node(rb_prev(&node->rb_hole_size));
 
 	case DRM_MM_INSERT_LOW:
 		return rb_hole_addr_to_node(rb_next(&node->rb_hole_addr));
@@ -426,6 +450,11 @@ int drm_mm_reserve_node(struct drm_mm *mm, struct drm_mm_node *node)
 }
 EXPORT_SYMBOL(drm_mm_reserve_node);
 
+static u64 rb_to_hole_size_or_zero(struct rb_node *rb)
+{
+	return rb ? rb_to_hole_size(rb) : 0;
+}
+
 /**
  * drm_mm_insert_node_in_range - ranged search for space and insert @node
  * @mm: drm_mm to allocate from
@@ -457,6 +486,9 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
 	if (unlikely(size == 0 || range_end - range_start < size))
 		return -ENOSPC;
 
+	if (rb_to_hole_size_or_zero(rb_first_cached(&mm->holes_size)) < size)
+		return -ENOSPC;
+
 	if (alignment <= 1)
 		alignment = 0;
 
@@ -587,9 +619,9 @@ void drm_mm_replace_node(struct drm_mm_node *old, struct drm_mm_node *new)
 
 	if (drm_mm_hole_follows(old)) {
 		list_replace(&old->hole_stack, &new->hole_stack);
-		rb_replace_node(&old->rb_hole_size,
-				&new->rb_hole_size,
-				&mm->holes_size);
+		rb_replace_node_cached(&old->rb_hole_size,
+				       &new->rb_hole_size,
+				       &mm->holes_size);
 		rb_replace_node(&old->rb_hole_addr,
 				&new->rb_hole_addr,
 				&mm->holes_addr);
@@ -885,7 +917,7 @@ void drm_mm_init(struct drm_mm *mm, u64 start, u64 size)
 
 	INIT_LIST_HEAD(&mm->hole_stack);
 	mm->interval_tree = RB_ROOT_CACHED;
-	mm->holes_size = RB_ROOT;
+	mm->holes_size = RB_ROOT_CACHED;
 	mm->holes_addr = RB_ROOT;
 
 	/* Clever trick to avoid a special case in the free hole tracking. */
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 101f566ae43d..e3aa3bfd4860 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -173,7 +173,7 @@ struct drm_mm {
 	struct drm_mm_node head_node;
 	/* Keep an interval_tree for fast lookup of drm_mm_nodes by address. */
 	struct rb_root_cached interval_tree;
-	struct rb_root holes_size;
+	struct rb_root_cached holes_size;
 	struct rb_root holes_addr;
 
 	unsigned long scan_active;
-- 
2.17.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* [PATCH 2/4] drm/mm: Add a search-by-address variant to only inspect a single hole
  2018-05-13  7:50 [PATCH 1/4] drm/mm: Reject over-sized allocation requests early Chris Wilson
@ 2018-05-13  7:50 ` Chris Wilson
  2018-05-18 10:03   ` Joonas Lahtinen
  2018-05-13  7:50 ` [PATCH 3/4] drm/i915: Limit searching for PIN_HIGH Chris Wilson
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 12+ messages in thread
From: Chris Wilson @ 2018-05-13  7:50 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

Searching for an available hole by address is slow, as there no
guarantee that a hole will be available and so we must walk over all
nodes in the rbtree before we determine the search was futile. In many
cases, the caller doesn't strictly care for the highest available hole
and was just opportunistically laying out the address space in a
preferred order. In such cases, the caller can accept any address and
would rather do so then do a slow walk.

To be able to mix search strategies, the caller wants to tell the drm_mm
how long to spend on the search. Without a good guide for what should be
the best split, start with a request to try once at most. That is return
the top-most (or lowest) hole if it fulfils the alignment and size
requirements.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 drivers/gpu/drm/drm_mm.c | 9 +++++++--
 include/drm/drm_mm.h     | 4 ++++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 7b4ad05fe1c0..b8e99e2a7c34 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -480,6 +480,7 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
 {
 	struct drm_mm_node *hole;
 	u64 remainder_mask;
+	bool once;
 
 	DRM_MM_BUG_ON(range_start >= range_end);
 
@@ -492,9 +493,13 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
 	if (alignment <= 1)
 		alignment = 0;
 
+	once = mode & DRM_MM_INSERT_END;
+	mode &= ~DRM_MM_INSERT_END;
+
 	remainder_mask = is_power_of_2(alignment) ? alignment - 1 : 0;
-	for (hole = first_hole(mm, range_start, range_end, size, mode); hole;
-	     hole = next_hole(mm, hole, mode)) {
+	for (hole = first_hole(mm, range_start, range_end, size, mode);
+	     hole;
+	     hole = once ? NULL : next_hole(mm, hole, mode)) {
 		u64 hole_start = __drm_mm_hole_node_start(hole);
 		u64 hole_end = hole_start + hole->hole_size;
 		u64 adj_start, adj_end;
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index e3aa3bfd4860..2a6351093d15 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -109,6 +109,10 @@ enum drm_mm_insert_mode {
 	 * Allocates the node from the bottom of the found hole.
 	 */
 	DRM_MM_INSERT_EVICT,
+
+	DRM_MM_INSERT_END = BIT(31),
+	DRM_MM_INSERT_HIGHEST = DRM_MM_INSERT_HIGH | DRM_MM_INSERT_END,
+	DRM_MM_INSERT_LOWEST = DRM_MM_INSERT_LOW | DRM_MM_INSERT_END,
 };
 
 /**
-- 
2.17.0

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

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

* [PATCH 3/4] drm/i915: Limit searching for PIN_HIGH
  2018-05-13  7:50 [PATCH 1/4] drm/mm: Reject over-sized allocation requests early Chris Wilson
  2018-05-13  7:50 ` [PATCH 2/4] drm/mm: Add a search-by-address variant to only inspect a single hole Chris Wilson
@ 2018-05-13  7:50 ` Chris Wilson
  2018-05-18 10:05   ` Joonas Lahtinen
  2018-05-13  7:50 ` [PATCH 4/4] drm/i915: Pin the ring high Chris Wilson
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 12+ messages in thread
From: Chris Wilson @ 2018-05-13  7:50 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
times), doing a search by address over a pathologically fragmented
address space is exceeding slow. To protect ourselves from nearly
unbounded latency (think searching a million holes while under
struct_mutex), limit the search for the highest available hole and
fallback to best-fit if it fails.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c01d6dbe269a..cc9eb5956c44 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3967,7 +3967,7 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
 
 	mode = DRM_MM_INSERT_BEST;
 	if (flags & PIN_HIGH)
-		mode = DRM_MM_INSERT_HIGH;
+		mode = DRM_MM_INSERT_HIGHEST;
 	if (flags & PIN_MAPPABLE)
 		mode = DRM_MM_INSERT_LOW;
 
@@ -3987,6 +3987,15 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
 	if (err != -ENOSPC)
 		return err;
 
+	if (mode & DRM_MM_INSERT_END) {
+		err = drm_mm_insert_node_in_range(&vm->mm, node,
+						  size, alignment, color,
+						  start, end,
+						  DRM_MM_INSERT_BEST);
+		if (err != -ENOSPC)
+			return err;
+	}
+
 	if (flags & PIN_NOEVICT)
 		return -ENOSPC;
 
-- 
2.17.0

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

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

* [PATCH 4/4] drm/i915: Pin the ring high
  2018-05-13  7:50 [PATCH 1/4] drm/mm: Reject over-sized allocation requests early Chris Wilson
  2018-05-13  7:50 ` [PATCH 2/4] drm/mm: Add a search-by-address variant to only inspect a single hole Chris Wilson
  2018-05-13  7:50 ` [PATCH 3/4] drm/i915: Limit searching for PIN_HIGH Chris Wilson
@ 2018-05-13  7:50 ` Chris Wilson
  2018-05-18 10:06   ` Joonas Lahtinen
  2018-05-13  8:16 ` ✓ Fi.CI.BAT: success for series starting with [1/4] drm/mm: Reject over-sized allocation requests early Patchwork
                   ` (2 subsequent siblings)
  5 siblings, 1 reply; 12+ messages in thread
From: Chris Wilson @ 2018-05-13  7:50 UTC (permalink / raw)
  To: dri-devel; +Cc: intel-gfx

If we can use an unmappable ring, try to pin it out of the mappable
aperture. This simple layout preference is to try and keep the mappable
aperture reserved and available to handle GGTT mmapping requests from
userspace without causing evictions and GPU stalls.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 8f19349a6055..cd4fb796d97d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1033,6 +1033,8 @@ int intel_ring_pin(struct intel_ring *ring,
 		flags |= PIN_OFFSET_BIAS | offset_bias;
 	if (vma->obj->stolen)
 		flags |= PIN_MAPPABLE;
+	else
+		flags |= PIN_HIGH;
 
 	if (!(vma->flags & I915_VMA_GLOBAL_BIND)) {
 		if (flags & PIN_MAPPABLE || map == I915_MAP_WC)
-- 
2.17.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* ✓ Fi.CI.BAT: success for series starting with [1/4] drm/mm: Reject over-sized allocation requests early
  2018-05-13  7:50 [PATCH 1/4] drm/mm: Reject over-sized allocation requests early Chris Wilson
                   ` (2 preceding siblings ...)
  2018-05-13  7:50 ` [PATCH 4/4] drm/i915: Pin the ring high Chris Wilson
@ 2018-05-13  8:16 ` Patchwork
  2018-05-13  9:15 ` ✓ Fi.CI.IGT: " Patchwork
  2018-05-18  9:56 ` [PATCH 1/4] " Joonas Lahtinen
  5 siblings, 0 replies; 12+ messages in thread
From: Patchwork @ 2018-05-13  8:16 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/4] drm/mm: Reject over-sized allocation requests early
URL   : https://patchwork.freedesktop.org/series/43097/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4171 -> Patchwork_8987 =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8987 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8987, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/43097/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8987:

  === IGT changes ===

    ==== Warnings ====

    igt@gem_exec_gttfill@basic:
      fi-pnv-d510:        SKIP -> PASS

    
== Known issues ==

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

  === IGT changes ===

    ==== Issues hit ====

    igt@gem_mmap_gtt@basic-small-bo-tiledx:
      fi-gdg-551:         PASS -> FAIL (fdo#102575)

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
      fi-bxt-dsi:         PASS -> INCOMPLETE (fdo#103927)

    
    ==== Possible fixes ====

    igt@drv_module_reload@basic-reload:
      fi-glk-j4005:       DMESG-WARN (fdo#106248) -> PASS

    igt@kms_chamelium@hdmi-hpd-fast:
      fi-kbl-7500u:       FAIL (fdo#102672, fdo#103841) -> SKIP

    
  fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
  fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248


== Participating hosts (40 -> 37) ==

  Missing    (3): fi-ilk-m540 fi-byt-squawks fi-skl-6700hq 


== Build changes ==

    * Linux: CI_DRM_4171 -> Patchwork_8987

  CI_DRM_4171: fe5bde58dca53de7b615789c69ed83c6420d2d1a @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4475: 35f08c12aa216d5b62a5b9984b575cee6905098f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8987: d21c6523d0a2aa741f2689994ebe4667c365cc85 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4475: 3ba0657bff4216d1ec7179935590261855f1651e @ git://anongit.freedesktop.org/piglit


== Linux commits ==

d21c6523d0a2 drm/i915: Pin the ring high
c1056fbef916 drm/i915: Limit searching for PIN_HIGH
c7873dc37960 drm/mm: Add a search-by-address variant to only inspect a single hole
a66cd48920bd drm/mm: Reject over-sized allocation requests early

== Logs ==

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

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

* ✓ Fi.CI.IGT: success for series starting with [1/4] drm/mm: Reject over-sized allocation requests early
  2018-05-13  7:50 [PATCH 1/4] drm/mm: Reject over-sized allocation requests early Chris Wilson
                   ` (3 preceding siblings ...)
  2018-05-13  8:16 ` ✓ Fi.CI.BAT: success for series starting with [1/4] drm/mm: Reject over-sized allocation requests early Patchwork
@ 2018-05-13  9:15 ` Patchwork
  2018-05-18  9:56 ` [PATCH 1/4] " Joonas Lahtinen
  5 siblings, 0 replies; 12+ messages in thread
From: Patchwork @ 2018-05-13  9:15 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/4] drm/mm: Reject over-sized allocation requests early
URL   : https://patchwork.freedesktop.org/series/43097/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4171_full -> Patchwork_8987_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8987_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8987_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/43097/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8987_full:

  === IGT changes ===

    ==== Warnings ====

    igt@gem_mocs_settings@mocs-rc6-vebox:
      shard-kbl:          PASS -> SKIP

    
== Known issues ==

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

  === IGT changes ===

    ==== Issues hit ====

    igt@gem_eio@in-flight-10ms:
      shard-glk:          PASS -> FAIL (fdo#105957)

    igt@gem_ppgtt@blt-vs-render-ctx0:
      shard-kbl:          PASS -> INCOMPLETE (fdo#103665, fdo#106023)

    igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
      shard-glk:          PASS -> FAIL (fdo#105312)

    igt@kms_vblank@pipe-a-ts-continuation-suspend:
      shard-kbl:          PASS -> DMESG-WARN (fdo#105602, fdo#103558)

    
    ==== Possible fixes ====

    igt@gem_exec_await@wide-contexts:
      shard-apl:          DMESG-FAIL -> PASS

    igt@kms_flip@2x-flip-vs-absolute-wf_vblank-interruptible:
      shard-hsw:          FAIL (fdo#103928) -> PASS

    igt@kms_flip@absolute-wf_vblank-interruptible:
      shard-glk:          FAIL (fdo#106087) -> PASS

    igt@kms_flip@flip-vs-expired-vblank-interruptible:
      shard-glk:          FAIL (fdo#105363, fdo#102887) -> PASS

    igt@kms_flip@plain-flip-ts-check:
      shard-glk:          FAIL (fdo#100368) -> PASS

    igt@kms_sysfs_edid_timing:
      shard-apl:          WARN (fdo#100047) -> PASS

    
  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#105312 https://bugs.freedesktop.org/show_bug.cgi?id=105312
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#105957 https://bugs.freedesktop.org/show_bug.cgi?id=105957
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

    * Linux: CI_DRM_4171 -> Patchwork_8987

  CI_DRM_4171: fe5bde58dca53de7b615789c69ed83c6420d2d1a @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4475: 35f08c12aa216d5b62a5b9984b575cee6905098f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8987: d21c6523d0a2aa741f2689994ebe4667c365cc85 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4475: 3ba0657bff4216d1ec7179935590261855f1651e @ git://anongit.freedesktop.org/piglit

== Logs ==

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

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

* Re: [PATCH 1/4] drm/mm: Reject over-sized allocation requests early
  2018-05-13  7:50 [PATCH 1/4] drm/mm: Reject over-sized allocation requests early Chris Wilson
                   ` (4 preceding siblings ...)
  2018-05-13  9:15 ` ✓ Fi.CI.IGT: " Patchwork
@ 2018-05-18  9:56 ` Joonas Lahtinen
  5 siblings, 0 replies; 12+ messages in thread
From: Joonas Lahtinen @ 2018-05-18  9:56 UTC (permalink / raw)
  To: Chris Wilson, dri-devel; +Cc: intel-gfx

Quoting Chris Wilson (2018-05-13 10:50:07)
> As we keep an rbtree of available holes sorted by their size, we can
> very easily determine if there is any hole large enough that might
> satisfy the allocation request. This helps when dealing with a highly
> fragmented address space and a request for a search by address.
> 
> To cache the largest size, we convert into the cached rbtree variant
> which tracks the leftmost node for us. However, currently we sorted into
> ascending size order so the leftmost node is the smallest, and so to
> make it the largest hole we need to invert our sorting.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

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

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

* Re: [PATCH 2/4] drm/mm: Add a search-by-address variant to only inspect a single hole
  2018-05-13  7:50 ` [PATCH 2/4] drm/mm: Add a search-by-address variant to only inspect a single hole Chris Wilson
@ 2018-05-18 10:03   ` Joonas Lahtinen
  0 siblings, 0 replies; 12+ messages in thread
From: Joonas Lahtinen @ 2018-05-18 10:03 UTC (permalink / raw)
  To: Chris Wilson, dri-devel; +Cc: intel-gfx

Quoting Chris Wilson (2018-05-13 10:50:08)
> Searching for an available hole by address is slow, as there no
> guarantee that a hole will be available and so we must walk over all
> nodes in the rbtree before we determine the search was futile. In many
> cases, the caller doesn't strictly care for the highest available hole
> and was just opportunistically laying out the address space in a
> preferred order. In such cases, the caller can accept any address and
> would rather do so then do a slow walk.
> 
> To be able to mix search strategies, the caller wants to tell the drm_mm
> how long to spend on the search. Without a good guide for what should be
> the best split, start with a request to try once at most. That is return
> the top-most (or lowest) hole if it fulfils the alignment and size
> requirements.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

<SNIP>

> +++ b/include/drm/drm_mm.h
> @@ -109,6 +109,10 @@ enum drm_mm_insert_mode {
>          * Allocates the node from the bottom of the found hole.
>          */
>         DRM_MM_INSERT_EVICT,
> +

Could definitely use a comment here.

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Regards, Joonas

> +       DRM_MM_INSERT_END = BIT(31),
> +       DRM_MM_INSERT_HIGHEST = DRM_MM_INSERT_HIGH | DRM_MM_INSERT_END,
> +       DRM_MM_INSERT_LOWEST = DRM_MM_INSERT_LOW | DRM_MM_INSERT_END,
>  };
>  
>  /**
> -- 
> 2.17.0
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: [PATCH 3/4] drm/i915: Limit searching for PIN_HIGH
  2018-05-13  7:50 ` [PATCH 3/4] drm/i915: Limit searching for PIN_HIGH Chris Wilson
@ 2018-05-18 10:05   ` Joonas Lahtinen
  2018-05-18 10:07     ` Chris Wilson
  0 siblings, 1 reply; 12+ messages in thread
From: Joonas Lahtinen @ 2018-05-18 10:05 UTC (permalink / raw)
  To: Chris Wilson, dri-devel; +Cc: intel-gfx

Quoting Chris Wilson (2018-05-13 10:50:09)
> To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
> times), doing a search by address over a pathologically fragmented
> address space is exceeding slow. To protect ourselves from nearly
> unbounded latency (think searching a million holes while under
> struct_mutex), limit the search for the highest available hole and
> fallback to best-fit if it fails.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Some testcase or measurement to quote before merging?

Code itself is;

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Regards, Joonas

> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index c01d6dbe269a..cc9eb5956c44 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3967,7 +3967,7 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
>  
>         mode = DRM_MM_INSERT_BEST;
>         if (flags & PIN_HIGH)
> -               mode = DRM_MM_INSERT_HIGH;
> +               mode = DRM_MM_INSERT_HIGHEST;
>         if (flags & PIN_MAPPABLE)
>                 mode = DRM_MM_INSERT_LOW;
>  
> @@ -3987,6 +3987,15 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
>         if (err != -ENOSPC)
>                 return err;
>  
> +       if (mode & DRM_MM_INSERT_END) {
> +               err = drm_mm_insert_node_in_range(&vm->mm, node,
> +                                                 size, alignment, color,
> +                                                 start, end,
> +                                                 DRM_MM_INSERT_BEST);
> +               if (err != -ENOSPC)
> +                       return err;
> +       }
> +
>         if (flags & PIN_NOEVICT)
>                 return -ENOSPC;
>  
> -- 
> 2.17.0
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: [PATCH 4/4] drm/i915: Pin the ring high
  2018-05-13  7:50 ` [PATCH 4/4] drm/i915: Pin the ring high Chris Wilson
@ 2018-05-18 10:06   ` Joonas Lahtinen
  0 siblings, 0 replies; 12+ messages in thread
From: Joonas Lahtinen @ 2018-05-18 10:06 UTC (permalink / raw)
  To: Chris Wilson, dri-devel; +Cc: intel-gfx

Quoting Chris Wilson (2018-05-13 10:50:10)
> If we can use an unmappable ring, try to pin it out of the mappable
> aperture. This simple layout preference is to try and keep the mappable
> aperture reserved and available to handle GGTT mmapping requests from
> userspace without causing evictions and GPU stalls.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

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

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

* Re: [PATCH 3/4] drm/i915: Limit searching for PIN_HIGH
  2018-05-18 10:05   ` Joonas Lahtinen
@ 2018-05-18 10:07     ` Chris Wilson
  2018-05-18 10:31       ` Joonas Lahtinen
  0 siblings, 1 reply; 12+ messages in thread
From: Chris Wilson @ 2018-05-18 10:07 UTC (permalink / raw)
  To: Joonas Lahtinen, dri-devel; +Cc: intel-gfx

Quoting Joonas Lahtinen (2018-05-18 11:05:36)
> Quoting Chris Wilson (2018-05-13 10:50:09)
> > To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
> > times), doing a search by address over a pathologically fragmented
> > address space is exceeding slow. To protect ourselves from nearly
> > unbounded latency (think searching a million holes while under
> > struct_mutex), limit the search for the highest available hole and
> > fallback to best-fit if it fails.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> 
> Some testcase or measurement to quote before merging?

igt/gem_ctx_thrash goes from hours to seconds.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: [PATCH 3/4] drm/i915: Limit searching for PIN_HIGH
  2018-05-18 10:07     ` Chris Wilson
@ 2018-05-18 10:31       ` Joonas Lahtinen
  0 siblings, 0 replies; 12+ messages in thread
From: Joonas Lahtinen @ 2018-05-18 10:31 UTC (permalink / raw)
  To: Chris Wilson, dri-devel; +Cc: intel-gfx

Quoting Chris Wilson (2018-05-18 13:07:16)
> Quoting Joonas Lahtinen (2018-05-18 11:05:36)
> > Quoting Chris Wilson (2018-05-13 10:50:09)
> > > To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
> > > times), doing a search by address over a pathologically fragmented
> > > address space is exceeding slow. To protect ourselves from nearly
> > > unbounded latency (think searching a million holes while under
> > > struct_mutex), limit the search for the highest available hole and
> > > fallback to best-fit if it fails.
> > > 
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > 
> > Some testcase or measurement to quote before merging?
> 
> igt/gem_ctx_thrash goes from hours to seconds.

Thats a good merit, do add it :)

Regards, Joonas

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

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

end of thread, other threads:[~2018-05-18 10:31 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-13  7:50 [PATCH 1/4] drm/mm: Reject over-sized allocation requests early Chris Wilson
2018-05-13  7:50 ` [PATCH 2/4] drm/mm: Add a search-by-address variant to only inspect a single hole Chris Wilson
2018-05-18 10:03   ` Joonas Lahtinen
2018-05-13  7:50 ` [PATCH 3/4] drm/i915: Limit searching for PIN_HIGH Chris Wilson
2018-05-18 10:05   ` Joonas Lahtinen
2018-05-18 10:07     ` Chris Wilson
2018-05-18 10:31       ` Joonas Lahtinen
2018-05-13  7:50 ` [PATCH 4/4] drm/i915: Pin the ring high Chris Wilson
2018-05-18 10:06   ` Joonas Lahtinen
2018-05-13  8:16 ` ✓ Fi.CI.BAT: success for series starting with [1/4] drm/mm: Reject over-sized allocation requests early Patchwork
2018-05-13  9:15 ` ✓ Fi.CI.IGT: " Patchwork
2018-05-18  9:56 ` [PATCH 1/4] " Joonas Lahtinen

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.