Re: [PATCH 14/37] drm/i915: Simple selftest to exercise live requests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxx>
> >---
> > 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux