From: Matthew Brost <matthew.brost@intel.com>
To: John Harrison <john.c.harrison@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/selftests: Add a cancel request selftest that triggers a reset
Date: Thu, 13 Jan 2022 10:01:28 -0800 [thread overview]
Message-ID: <20220113180128.GA20915@jons-linux-dev-box> (raw)
In-Reply-To: <bc06adfc-d676-a687-678b-97ff64886537@intel.com>
On Thu, Jan 13, 2022 at 09:59:35AM -0800, John Harrison wrote:
> On 1/13/2022 09:34, Matthew Brost wrote:
> > On Thu, Jan 13, 2022 at 09:33:12AM -0800, John Harrison wrote:
> > > On 1/11/2022 15:11, Matthew Brost wrote:
> > > > Add a cancel request selftest that results in an engine reset to cancel
> > > > the request as it is non-preemptable. Also insert a NOP request after
> > > > the cancelled request and confirm that it completes successfully.
> > > >
> > > > v2:
> > > > (Tvrtko)
> > > > - Skip test if preemption timeout compiled out
> > > > - Skip test if engine reset isn't supported
> > > > - Update debug prints to be more descriptive
> > > > v3:
> > > > - Add comment explaining test
> > > >
> > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/selftests/i915_request.c | 117 ++++++++++++++++++
> > > > 1 file changed, 117 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c b/drivers/gpu/drm/i915/selftests/i915_request.c
> > > > index 7f66f6d299b26..f78de99d5ae1e 100644
> > > > --- a/drivers/gpu/drm/i915/selftests/i915_request.c
> > > > +++ b/drivers/gpu/drm/i915/selftests/i915_request.c
> > > > @@ -782,6 +782,115 @@ static int __cancel_completed(struct intel_engine_cs *engine)
> > > > return err;
> > > > }
> > > > +/*
> > > > + * Test to prove a non-preemptable request can be cancelled and a subsequent
> > > > + * request on the same context can successfully complete after cancallation.
> > > cancellation
> > >
> > Yep.
> >
> > > > + *
> > > > + * Testing methodology is to create non-preemptable request and submit it,
> > > a non-preemptible
> > >
> > Yep.
> >
> > > > + * wait for spinner to start, create a NOP request and submit it, cancel the
> > > > + * spinner, wait for spinner to complete and verify it failed with an error,
> > > > + * finally wait for NOP request to complete verify it succeeded without an
> > > > + * error. Preemption timeout also reduced / restored so test runs in a timely
> > > > + * maner.
> > > > + */
> > > > +static int __cancel_reset(struct drm_i915_private *i915,
> > > > + struct intel_engine_cs *engine)
> > > > +{
> > > > + struct intel_context *ce;
> > > > + struct igt_spinner spin;
> > > > + struct i915_request *rq, *nop;
> > > > + unsigned long preempt_timeout_ms;
> > > > + int err = 0;
> > > > +
> > > > + if (!CONFIG_DRM_I915_PREEMPT_TIMEOUT ||
> > > Does this matter? The test is overriding the default anyway.
> > >
> > Yes. Execlists don't try to preempt anything if
> > CONFIG_DRM_I915_PREEMPT_TIMEOUT is turned off. If we wan't to avoid the
> > cancelation doing a full GT reset, CONFIG_DRM_I915_PREEMPT_TIMEOUT
> > should be turned on.
> Hmm, I would read that as a bug. The description for the config parameter
> is:
> "This is adjustable via
> /sys/class/drm/card?/engine/*/preempt_timeout_ms
>
> May be 0 to disable the timeout.
>
> The compiled in default may get overridden at driver probe time on
> certain platforms and certain engines which will be reflected in
> the
> sysfs control."
>
> I would take that as meaning that even if the compiled in default is zero,
> the user or even the i915 driver itself could override that at runtime and
> enable pre-emption again. So having any code use this as a flag is broken.
> Indeed, any code other than 'engine->default_preempt_timeout =
> CONFIG_PREEMPT_TIMEOUT' is broken, IMHO.
>
Can't really argue against you here.
> But maybe that's for a different patch. If the driver is already behaving
> badly and doing the correct thing here will actually cause test failures
> then you can't really do much other than follow the existing bad behaviour.
>
Yea, agree it is out of scope this patch / series. We can cleanup the
execlists code in a follow up patch if needed + loop in an execlists
expert for a reviewer. Maybe there is a unknown reason that code is
doing this?
Matt
> John.
>
>
> > > > + !intel_has_reset_engine(engine->gt))
> > > > + return 0;
> > > > +
> > > > + preempt_timeout_ms = engine->props.preempt_timeout_ms;
> > > > + engine->props.preempt_timeout_ms = 100;
> > > > +
> > > > + if (igt_spinner_init(&spin, engine->gt))
> > > > + goto out_restore;
> > > > +
> > > > + ce = intel_context_create(engine);
> > > > + if (IS_ERR(ce)) {
> > > > + err = PTR_ERR(ce);
> > > > + goto out_spin;
> > > > + }
> > > > +
> > > > + rq = igt_spinner_create_request(&spin, ce, MI_NOOP);
> > > > + if (IS_ERR(rq)) {
> > > > + err = PTR_ERR(rq);
> > > > + goto out_ce;
> > > > + }
> > > > +
> > > > + pr_debug("%s: Cancelling active non-preemptable request\n",
> > > > + engine->name);
> > > > + i915_request_get(rq);
> > > > + i915_request_add(rq);
> > > > + if (!igt_wait_for_spinner(&spin, rq)) {
> > > > + struct drm_printer p = drm_info_printer(engine->i915->drm.dev);
> > > > +
> > > > + pr_err("Failed to start spinner on %s\n", engine->name);
> > > > + intel_engine_dump(engine, &p, "%s\n", engine->name);
> > > > + err = -ETIME;
> > > > + goto out_rq;
> > > > + }
> > > > +
> > > > + nop = intel_context_create_request(ce);
> > > > + if (IS_ERR(nop))
> > > > + goto out_nop;
> > > Should be out_rq?
> > >
> > Yes, it should.
> >
> > Matt
> >
> > > John.
> > >
> > >
> > > > + i915_request_get(nop);
> > > > + i915_request_add(nop);
> > > > +
> > > > + i915_request_cancel(rq, -EINTR);
> > > > +
> > > > + if (i915_request_wait(rq, 0, HZ) < 0) {
> > > > + struct drm_printer p = drm_info_printer(engine->i915->drm.dev);
> > > > +
> > > > + pr_err("%s: Failed to cancel hung request\n", engine->name);
> > > > + intel_engine_dump(engine, &p, "%s\n", engine->name);
> > > > + err = -ETIME;
> > > > + goto out_nop;
> > > > + }
> > > > +
> > > > + if (rq->fence.error != -EINTR) {
> > > > + pr_err("%s: fence not cancelled (%u)\n",
> > > > + engine->name, rq->fence.error);
> > > > + err = -EINVAL;
> > > > + goto out_nop;
> > > > + }
> > > > +
> > > > + if (i915_request_wait(nop, 0, HZ) < 0) {
> > > > + struct drm_printer p = drm_info_printer(engine->i915->drm.dev);
> > > > +
> > > > + pr_err("%s: Failed to complete nop request\n", engine->name);
> > > > + intel_engine_dump(engine, &p, "%s\n", engine->name);
> > > > + err = -ETIME;
> > > > + goto out_nop;
> > > > + }
> > > > +
> > > > + if (nop->fence.error != 0) {
> > > > + pr_err("%s: Nop request errored (%u)\n",
> > > > + engine->name, nop->fence.error);
> > > > + err = -EINVAL;
> > > > + }
> > > > +
> > > > +out_nop:
> > > > + i915_request_put(nop);
> > > > +out_rq:
> > > > + i915_request_put(rq);
> > > > +out_ce:
> > > > + intel_context_put(ce);
> > > > +out_spin:
> > > > + igt_spinner_fini(&spin);
> > > > +out_restore:
> > > > + engine->props.preempt_timeout_ms = preempt_timeout_ms;
> > > > + if (err)
> > > > + pr_err("%s: %s error %d\n", __func__, engine->name, err);
> > > > + return err;
> > > > +}
> > > > +
> > > > static int live_cancel_request(void *arg)
> > > > {
> > > > struct drm_i915_private *i915 = arg;
> > > > @@ -814,6 +923,14 @@ static int live_cancel_request(void *arg)
> > > > return err;
> > > > if (err2)
> > > > return err2;
> > > > +
> > > > + /* Expects reset so call outside of igt_live_test_* */
> > > > + err = __cancel_reset(i915, engine);
> > > > + if (err)
> > > > + return err;
> > > > +
> > > > + if (igt_flush_test(i915))
> > > > + return -EIO;
> > > > }
> > > > return 0;
>
next prev parent reply other threads:[~2022-01-13 18:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-11 23:11 [Intel-gfx] [PATCH 0/2] Remove some hacks required for GuC 62.0.0 Matthew Brost
2022-01-11 23:11 ` [Intel-gfx] [PATCH 1/2] drm/i915/selftests: Add a cancel request selftest that triggers a reset Matthew Brost
2022-01-13 17:33 ` John Harrison
2022-01-13 17:34 ` Matthew Brost
2022-01-13 17:59 ` John Harrison
2022-01-13 18:01 ` Matthew Brost [this message]
2022-01-11 23:11 ` [Intel-gfx] [PATCH 2/2] drm/i915/guc: Remove hacks for reset and schedule disable G2H being received out of order Matthew Brost
2022-01-13 17:35 ` John Harrison
2022-01-12 0:23 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Remove some hacks required for GuC 62.0.0 Patchwork
2022-01-12 0:54 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-01-12 8:18 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2022-01-13 18:13 [Intel-gfx] [PATCH 0/2] " Matthew Brost
2022-01-13 18:13 ` [Intel-gfx] [PATCH 1/2] drm/i915/selftests: Add a cancel request selftest that triggers a reset Matthew Brost
2022-01-13 18:37 ` John Harrison
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220113180128.GA20915@jons-linux-dev-box \
--to=matthew.brost@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=john.c.harrison@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox