* [PATCH] drm/i915: Track number of pending freed objects
@ 2018-02-19 16:19 Chris Wilson
2018-02-19 16:46 ` ✓ Fi.CI.BAT: success for " Patchwork
` (6 more replies)
0 siblings, 7 replies; 10+ messages in thread
From: Chris Wilson @ 2018-02-19 16:19 UTC (permalink / raw)
To: intel-gfx
During igt, we frequently call into the driver to reset both HW and
driver state (idling the device, waiting for it to become idle and
freeing off old objects) to ensure that we start each test/subtest/pass
from known state. This process incurs an RCU barrier or two to ensure
that any such pending frees are indeed flushed before we return.
However, unconditionally waiting on the RCU barrier adds needless delay
to many callers, which adds up to several seconds when repeated thousands
of times. We can skip the rcu_barrier() if by tracking how many outstanding
frees we have, we know there are none.
The same path is used along suspend, where we may be able to save the
unconditional RCU barrier.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
drivers/gpu/drm/i915/i915_drv.h | 8 ++++++++
drivers/gpu/drm/i915/i915_gem.c | 4 ++++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6b215c411338..76bfe909168c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1095,6 +1095,11 @@ struct i915_gem_mm {
struct llist_head free_list;
struct work_struct free_work;
spinlock_t free_lock;
+ /**
+ * Count of objects pending destructions. Used to skip needlessly
+ * waiting on an RCU barrier if no objects are waiting to be freed.
+ */
+ atomic_t free_count;
/**
* Small stash of WC pages
@@ -3134,6 +3139,9 @@ void i915_gem_free_object(struct drm_gem_object *obj);
static inline void i915_gem_drain_freed_objects(struct drm_i915_private *i915)
{
+ if (!atomic_read(&i915->mm.free_count))
+ return;
+
/* A single pass should suffice to release all the freed objects (along
* most call paths) , but be a little more paranoid in that freeing
* the objects does take a little amount of time, during which the rcu
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f530cd247724..f2dcf09f4ebc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4758,6 +4758,9 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915,
kfree(obj->bit_17);
i915_gem_object_free(obj);
+ GEM_BUG_ON(!atomic_read(&i915->mm.free_count));
+ atomic_dec(&i915->mm.free_count);
+
if (on)
cond_resched();
}
@@ -4846,6 +4849,7 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
* i915_gem_busy_ioctl(). For the corresponding synchronized
* lookup see i915_gem_object_lookup_rcu().
*/
+ atomic_inc(&to_i915(obj->base.dev)->mm.free_count);
call_rcu(&obj->rcu, __i915_gem_free_object_rcu);
}
--
2.16.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 10+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: Track number of pending freed objects
2018-02-19 16:19 [PATCH] drm/i915: Track number of pending freed objects Chris Wilson
@ 2018-02-19 16:46 ` Patchwork
2018-02-19 18:13 ` [PATCH] " Tvrtko Ursulin
` (5 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2018-02-19 16:46 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Track number of pending freed objects
URL : https://patchwork.freedesktop.org/series/38537/
State : success
== Summary ==
Series 38537v1 drm/i915: Track number of pending freed objects
https://patchwork.freedesktop.org/api/1.0/series/38537/revisions/1/mbox/
Test debugfs_test:
Subgroup read_all_entries:
pass -> INCOMPLETE (fi-snb-2520m) fdo#103713
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:417s
fi-bdw-gvtdvm total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:425s
fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:375s
fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:486s
fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:286s
fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:481s
fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:481s
fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:466s
fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:455s
fi-cfl-s2 total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:573s
fi-cnl-y3 total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:577s
fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:415s
fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:282s
fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:510s
fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:391s
fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:410s
fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:460s
fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:412s
fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:454s
fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:492s
fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:455s
fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:498s
fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:588s
fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:428s
fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:504s
fi-skl-6700hq total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:522s
fi-skl-6700k2 total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:499s
fi-skl-6770hq total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:486s
fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:416s
fi-skl-gvtdvm total:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:429s
fi-snb-2520m total:3 pass:2 dwarn:0 dfail:0 fail:0 skip:0
fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:395s
92b39eb6f5625c0a1d4c82c1894ac8ad885b187e drm-tip: 2018y-02m-19d-15h-50m-23s UTC integration manifest
867303ec83ea drm/i915: Track number of pending freed objects
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8068/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/i915: Track number of pending freed objects
2018-02-19 16:19 [PATCH] drm/i915: Track number of pending freed objects Chris Wilson
2018-02-19 16:46 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2018-02-19 18:13 ` Tvrtko Ursulin
2018-02-19 18:17 ` Chris Wilson
2018-02-19 21:31 ` ✗ Fi.CI.IGT: warning for " Patchwork
` (4 subsequent siblings)
6 siblings, 1 reply; 10+ messages in thread
From: Tvrtko Ursulin @ 2018-02-19 18:13 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
On 19/02/2018 16:19, Chris Wilson wrote:
> During igt, we frequently call into the driver to reset both HW and
> driver state (idling the device, waiting for it to become idle and
> freeing off old objects) to ensure that we start each test/subtest/pass
> from known state. This process incurs an RCU barrier or two to ensure
> that any such pending frees are indeed flushed before we return.
> However, unconditionally waiting on the RCU barrier adds needless delay
> to many callers, which adds up to several seconds when repeated thousands
> of times. We can skip the rcu_barrier() if by tracking how many outstanding
> frees we have, we know there are none.
To be pedantic it is not skipping the rcu_barrier, but skipping the
drain altogether.
So theoretically there is a tiny difference in behaviour where today
drain would wait for all frees currently executing, where after the
patch it will ignore these and only process the ones which got to the
end of the function.
Perhaps it atomic_inc was at the very top of i915_gem_free_object it
would be closer to today. But such suggestions feel extremely iffy.
Nosing around the code base suggest the change is completely fine. Only
potentially relevant site which might care about the subtle difference
is i915_gem_freeze_late, which actually doesnt care since everything has
been frozen at that point. So all frees have presumably exited and
incremented the new counter.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
>
> The same path is used along suspend, where we may be able to save the
> unconditional RCU barrier.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 8 ++++++++
> drivers/gpu/drm/i915/i915_gem.c | 4 ++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6b215c411338..76bfe909168c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1095,6 +1095,11 @@ struct i915_gem_mm {
> struct llist_head free_list;
> struct work_struct free_work;
> spinlock_t free_lock;
> + /**
> + * Count of objects pending destructions. Used to skip needlessly
> + * waiting on an RCU barrier if no objects are waiting to be freed.
> + */
> + atomic_t free_count;
>
> /**
> * Small stash of WC pages
> @@ -3134,6 +3139,9 @@ void i915_gem_free_object(struct drm_gem_object *obj);
>
> static inline void i915_gem_drain_freed_objects(struct drm_i915_private *i915)
> {
> + if (!atomic_read(&i915->mm.free_count))
> + return;
> +
> /* A single pass should suffice to release all the freed objects (along
> * most call paths) , but be a little more paranoid in that freeing
> * the objects does take a little amount of time, during which the rcu
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f530cd247724..f2dcf09f4ebc 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4758,6 +4758,9 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915,
> kfree(obj->bit_17);
> i915_gem_object_free(obj);
>
> + GEM_BUG_ON(!atomic_read(&i915->mm.free_count));
> + atomic_dec(&i915->mm.free_count);
> +
> if (on)
> cond_resched();
> }
> @@ -4846,6 +4849,7 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
> * i915_gem_busy_ioctl(). For the corresponding synchronized
> * lookup see i915_gem_object_lookup_rcu().
> */
> + atomic_inc(&to_i915(obj->base.dev)->mm.free_count);
> call_rcu(&obj->rcu, __i915_gem_free_object_rcu);
> }
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/i915: Track number of pending freed objects
2018-02-19 18:13 ` [PATCH] " Tvrtko Ursulin
@ 2018-02-19 18:17 ` Chris Wilson
0 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2018-02-19 18:17 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx
Quoting Tvrtko Ursulin (2018-02-19 18:13:13)
>
> On 19/02/2018 16:19, Chris Wilson wrote:
> > During igt, we frequently call into the driver to reset both HW and
> > driver state (idling the device, waiting for it to become idle and
> > freeing off old objects) to ensure that we start each test/subtest/pass
> > from known state. This process incurs an RCU barrier or two to ensure
> > that any such pending frees are indeed flushed before we return.
> > However, unconditionally waiting on the RCU barrier adds needless delay
> > to many callers, which adds up to several seconds when repeated thousands
> > of times. We can skip the rcu_barrier() if by tracking how many outstanding
> > frees we have, we know there are none.
>
> To be pedantic it is not skipping the rcu_barrier, but skipping the
> drain altogether.
>
> So theoretically there is a tiny difference in behaviour where today
> drain would wait for all frees currently executing, where after the
> patch it will ignore these and only process the ones which got to the
> end of the function.
>
> Perhaps it atomic_inc was at the very top of i915_gem_free_object it
> would be closer to today. But such suggestions feel extremely iffy.
That's a smallish window. And it exists even today, with a race after
the RCU grace period (if you let userspace race with itself). I think
it's fair to say that we are dependent upon single-threaded client
operation here (either igt or suspend) for defined behaviour.
> Nosing around the code base suggest the change is completely fine. Only
> potentially relevant site which might care about the subtle difference
> is i915_gem_freeze_late, which actually doesnt care since everything has
> been frozen at that point. So all frees have presumably exited and
> incremented the new counter.
That's the idea at least :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* ✗ Fi.CI.IGT: warning for drm/i915: Track number of pending freed objects
2018-02-19 16:19 [PATCH] drm/i915: Track number of pending freed objects Chris Wilson
2018-02-19 16:46 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-02-19 18:13 ` [PATCH] " Tvrtko Ursulin
@ 2018-02-19 21:31 ` Patchwork
2018-02-19 21:44 ` [PATCH] " Chris Wilson
` (3 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2018-02-19 21:31 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Track number of pending freed objects
URL : https://patchwork.freedesktop.org/series/38537/
State : warning
== Summary ==
Test perf:
Subgroup oa-exponents:
fail -> PASS (shard-apl) fdo#102254
Subgroup buffer-fill:
pass -> FAIL (shard-apl) fdo#103755
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-indfb-draw-render:
fail -> PASS (shard-snb) fdo#101623
Test pm_rc6_residency:
Subgroup rc6-accuracy:
pass -> SKIP (shard-snb)
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
shard-apl total:3361 pass:1749 dwarn:1 dfail:0 fail:13 skip:1597 time:12022s
shard-hsw total:3434 pass:1762 dwarn:1 dfail:0 fail:2 skip:1668 time:11619s
shard-snb total:3434 pass:1351 dwarn:1 dfail:0 fail:3 skip:2079 time:6539s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8068/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] drm/i915: Track number of pending freed objects
2018-02-19 16:19 [PATCH] drm/i915: Track number of pending freed objects Chris Wilson
` (2 preceding siblings ...)
2018-02-19 21:31 ` ✗ Fi.CI.IGT: warning for " Patchwork
@ 2018-02-19 21:44 ` Chris Wilson
2018-02-19 22:06 ` [PATCH v2] " Chris Wilson
` (2 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2018-02-19 21:44 UTC (permalink / raw)
To: intel-gfx
Quoting Chris Wilson (2018-02-19 16:19:21)
> During igt, we frequently call into the driver to reset both HW and
> driver state (idling the device, waiting for it to become idle and
> freeing off old objects) to ensure that we start each test/subtest/pass
> from known state. This process incurs an RCU barrier or two to ensure
> that any such pending frees are indeed flushed before we return.
> However, unconditionally waiting on the RCU barrier adds needless delay
> to many callers, which adds up to several seconds when repeated thousands
> of times. We can skip the rcu_barrier() if by tracking how many outstanding
> frees we have, we know there are none.
>
> The same path is used along suspend, where we may be able to save the
> unconditional RCU barrier.
To put it into perspective with a completely meaningless
microbenchmark, igt/gem_sync/idle is improved from 50ms to 30us on bdw.
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2] drm/i915: Track number of pending freed objects
2018-02-19 16:19 [PATCH] drm/i915: Track number of pending freed objects Chris Wilson
` (3 preceding siblings ...)
2018-02-19 21:44 ` [PATCH] " Chris Wilson
@ 2018-02-19 22:06 ` Chris Wilson
2018-02-19 22:43 ` ✓ Fi.CI.BAT: success for drm/i915: Track number of pending freed objects (rev2) Patchwork
2018-02-20 1:40 ` ✗ Fi.CI.IGT: warning " Patchwork
6 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2018-02-19 22:06 UTC (permalink / raw)
To: intel-gfx
During igt, we frequently call into the driver to reset both HW and
driver state (idling the device, waiting for it to become idle and
freeing off old objects) to ensure that we start each test/subtest/pass
from known state. This process incurs an RCU barrier or two to ensure
that any such pending frees are indeed flushed before we return.
However, unconditionally waiting on the RCU barrier adds needless delay
to many callers, which adds up to several seconds when repeated thousands
of times. We can skip the rcu_barrier() if by tracking how many outstanding
frees we have, we know there are none.
The same path is used along suspend, where we may be able to save the
unconditional RCU barrier.
To put it into perspective with a completely meaningless
microbenchmark, igt/gem_sync/idle is improved from 50ms to 30us on bdw.
v2: Remove the extra synchronize_rcu() inside i915_drop_caches_set()
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +---
drivers/gpu/drm/i915/i915_drv.h | 8 ++++++++
drivers/gpu/drm/i915/i915_gem.c | 7 ++++++-
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 0cbe154e517d..05b41045b8f9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4079,10 +4079,8 @@ i915_drop_caches_set(void *data, u64 val)
if (val & DROP_IDLE)
drain_delayed_work(&dev_priv->gt.idle_work);
- if (val & DROP_FREED) {
- synchronize_rcu();
+ if (val & DROP_FREED)
i915_gem_drain_freed_objects(dev_priv);
- }
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6b215c411338..76bfe909168c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1095,6 +1095,11 @@ struct i915_gem_mm {
struct llist_head free_list;
struct work_struct free_work;
spinlock_t free_lock;
+ /**
+ * Count of objects pending destructions. Used to skip needlessly
+ * waiting on an RCU barrier if no objects are waiting to be freed.
+ */
+ atomic_t free_count;
/**
* Small stash of WC pages
@@ -3134,6 +3139,9 @@ void i915_gem_free_object(struct drm_gem_object *obj);
static inline void i915_gem_drain_freed_objects(struct drm_i915_private *i915)
{
+ if (!atomic_read(&i915->mm.free_count))
+ return;
+
/* A single pass should suffice to release all the freed objects (along
* most call paths) , but be a little more paranoid in that freeing
* the objects does take a little amount of time, during which the rcu
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f530cd247724..631a2db2bb6e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4758,6 +4758,9 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915,
kfree(obj->bit_17);
i915_gem_object_free(obj);
+ GEM_BUG_ON(!atomic_read(&i915->mm.free_count));
+ atomic_dec(&i915->mm.free_count);
+
if (on)
cond_resched();
}
@@ -4846,6 +4849,7 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
* i915_gem_busy_ioctl(). For the corresponding synchronized
* lookup see i915_gem_object_lookup_rcu().
*/
+ atomic_inc(&to_i915(obj->base.dev)->mm.free_count);
call_rcu(&obj->rcu, __i915_gem_free_object_rcu);
}
@@ -5546,7 +5550,8 @@ i915_gem_load_init(struct drm_i915_private *dev_priv)
void i915_gem_load_cleanup(struct drm_i915_private *dev_priv)
{
i915_gem_drain_freed_objects(dev_priv);
- WARN_ON(!llist_empty(&dev_priv->mm.free_list));
+ GEM_BUG_ON(!llist_empty(&dev_priv->mm.free_list));
+ GEM_BUG_ON(atomic_read(&dev_priv->mm.free_count));
WARN_ON(dev_priv->mm.object_count);
mutex_lock(&dev_priv->drm.struct_mutex);
--
2.16.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 10+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: Track number of pending freed objects (rev2)
2018-02-19 16:19 [PATCH] drm/i915: Track number of pending freed objects Chris Wilson
` (4 preceding siblings ...)
2018-02-19 22:06 ` [PATCH v2] " Chris Wilson
@ 2018-02-19 22:43 ` Patchwork
2018-02-20 1:40 ` ✗ Fi.CI.IGT: warning " Patchwork
6 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2018-02-19 22:43 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Track number of pending freed objects (rev2)
URL : https://patchwork.freedesktop.org/series/38537/
State : success
== Summary ==
Series 38537v2 drm/i915: Track number of pending freed objects
https://patchwork.freedesktop.org/api/1.0/series/38537/revisions/2/mbox/
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass -> DMESG-WARN (fi-cnl-y3) fdo#103191
Subgroup suspend-read-crc-pipe-b:
pass -> INCOMPLETE (fi-snb-2520m) fdo#103713
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:416s
fi-bdw-gvtdvm total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:424s
fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:372s
fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:482s
fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:282s
fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:479s
fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:481s
fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:463s
fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:451s
fi-cfl-s2 total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:559s
fi-cnl-y3 total:288 pass:261 dwarn:1 dfail:0 fail:0 skip:26 time:578s
fi-elk-e7500 total:288 pass:229 dwarn:0 dfail:0 fail:0 skip:59 time:407s
fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:280s
fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:505s
fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:385s
fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:409s
fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:443s
fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:416s
fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:448s
fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:486s
fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:446s
fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:491s
fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:581s
fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:435s
fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:498s
fi-skl-6700hq total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:516s
fi-skl-6700k2 total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:488s
fi-skl-6770hq total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:475s
fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:406s
fi-skl-gvtdvm total:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:428s
fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33
fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:390s
2ca2a369fc68ac59f42f359b62a978273425e531 drm-tip: 2018y-02m-19d-20h-39m-49s UTC integration manifest
63be55bb6e06 drm/i915: Track number of pending freed objects
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8070/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* ✗ Fi.CI.IGT: warning for drm/i915: Track number of pending freed objects (rev2)
2018-02-19 16:19 [PATCH] drm/i915: Track number of pending freed objects Chris Wilson
` (5 preceding siblings ...)
2018-02-19 22:43 ` ✓ Fi.CI.BAT: success for drm/i915: Track number of pending freed objects (rev2) Patchwork
@ 2018-02-20 1:40 ` Patchwork
2018-02-20 9:12 ` Chris Wilson
6 siblings, 1 reply; 10+ messages in thread
From: Patchwork @ 2018-02-20 1:40 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Track number of pending freed objects (rev2)
URL : https://patchwork.freedesktop.org/series/38537/
State : warning
== Summary ==
Test gem_eio:
Subgroup in-flight:
pass -> FAIL (shard-hsw) fdo#104676
Test kms_mmap_write_crc:
pass -> SKIP (shard-apl)
Test kms_setmode:
Subgroup basic:
pass -> FAIL (shard-hsw) fdo#99912
Test perf:
Subgroup oa-exponents:
pass -> FAIL (shard-apl) fdo#102254
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
shard-apl total:3343 pass:1751 dwarn:1 dfail:0 fail:13 skip:1577 time:12039s
shard-hsw total:3434 pass:1761 dwarn:1 dfail:0 fail:3 skip:1668 time:11779s
shard-snb total:3434 pass:1352 dwarn:1 dfail:0 fail:2 skip:2079 time:6624s
Blacklisted hosts:
shard-kbl total:3410 pass:1915 dwarn:1 dfail:0 fail:13 skip:1479 time:8963s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8070/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ✗ Fi.CI.IGT: warning for drm/i915: Track number of pending freed objects (rev2)
2018-02-20 1:40 ` ✗ Fi.CI.IGT: warning " Patchwork
@ 2018-02-20 9:12 ` Chris Wilson
0 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2018-02-20 9:12 UTC (permalink / raw)
To: Patchwork; +Cc: intel-gfx
Quoting Patchwork (2018-02-20 01:40:51)
> == Series Details ==
>
> Series: drm/i915: Track number of pending freed objects (rev2)
> URL : https://patchwork.freedesktop.org/series/38537/
> State : warning
>
> == Summary ==
>
> Test gem_eio:
> Subgroup in-flight:
> pass -> FAIL (shard-hsw) fdo#104676
> Test kms_mmap_write_crc:
> pass -> SKIP (shard-apl)
> Test kms_setmode:
> Subgroup basic:
> pass -> FAIL (shard-hsw) fdo#99912
> Test perf:
> Subgroup oa-exponents:
> pass -> FAIL (shard-apl) fdo#102254
Good news, the object leak detectors (which depend on the RCU flushing)
were stable so DROP_FREED still appears to be working.
Pushed to dinq, thanks for the review.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-02-20 9:12 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-19 16:19 [PATCH] drm/i915: Track number of pending freed objects Chris Wilson
2018-02-19 16:46 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-02-19 18:13 ` [PATCH] " Tvrtko Ursulin
2018-02-19 18:17 ` Chris Wilson
2018-02-19 21:31 ` ✗ Fi.CI.IGT: warning for " Patchwork
2018-02-19 21:44 ` [PATCH] " Chris Wilson
2018-02-19 22:06 ` [PATCH v2] " Chris Wilson
2018-02-19 22:43 ` ✓ Fi.CI.BAT: success for drm/i915: Track number of pending freed objects (rev2) Patchwork
2018-02-20 1:40 ` ✗ Fi.CI.IGT: warning " Patchwork
2018-02-20 9:12 ` Chris Wilson
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.