[Intel-gfx] [PATCH 14/37] drm/i915: Simple selftest to exercise live requests

Chris Wilson chris at chris-wilson.co.uk
Thu Jan 12 12:20:07 UTC 2017


On Thu, Jan 12, 2017 at 12:10:08PM +0000, Tvrtko Ursulin wrote:
> 
> On 11/01/2017 21:09, Chris Wilson wrote:
> >Just create several batches of requests and expect it to not fall over!
> >
> >Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >---
> > drivers/gpu/drm/i915/selftests/i915_gem_request.c  | 78 ++++++++++++++++++++++
> > .../gpu/drm/i915/selftests/i915_live_selftests.h   |  1 +
> > 2 files changed, 79 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_request.c b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
> >index f348f5f81351..63e69d360764 100644
> >--- a/drivers/gpu/drm/i915/selftests/i915_gem_request.c
> >+++ b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
> >@@ -22,6 +22,8 @@
> >  *
> >  */
> >
> >+#include <linux/prime_numbers.h>
> >+
> > #include "i915_selftest.h"
> >
> > #include "mock_gem_device.h"
> >@@ -155,3 +157,79 @@ int i915_gem_request_mock_selftests(void)
> >
> > 	return err;
> > }
> >+
> >+static int live_nop_request(void *arg)
> >+{
> >+	I915_SELFTEST_TIMEOUT(end_time);
> >+	struct drm_i915_private *i915 = arg;
> >+	struct drm_i915_gem_request *request;
> >+	unsigned int reset_count = i915_reset_count(&i915->gpu_error);
> >+	unsigned long n, prime;
> >+	ktime_t times[2] = {};
> >+	int err;
> >+
> >+	mutex_lock(&i915->drm.struct_mutex);
> >+
> >+	err = i915_gem_wait_for_idle(i915, I915_WAIT_LOCKED);
> >+	if (err) {
> >+		pr_err("Failed to idle GPU before %s\n", __func__);
> >+		goto out_unlock;
> >+	}
> >+
> >+	i915->gpu_error.missed_irq_rings = 0;
> >+
> >+	for_each_prime_number_from(prime, 1, 8192) {
> 
> Feels like an overuse of primes. Wouldn't an exponential sequence
> make more sense here? Like 1, 10, 100, 1000, if not even 100 would
> be enough.

Heh, everything is a nail right! I do like testing with primes though,
since powers-of-two are frequently optimised (I don't claim we should
hit any on this path). It just feels more likely to find issues by
avoiding testing with "simple" values, and the goal is find bugs in next
year's patches so serendipity rules.
 
> Also since it is a live test, might be cool to loop over the engines.

Good idea.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list