From: John Harrison <john.c.harrison@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
<IGT-Dev@Lists.FreeDesktop.Org>
Subject: Re: [PATCH i-g-t] tests/intel/gem_watchdog: Reduced timeouts for worst case scenario
Date: Thu, 15 Feb 2024 17:33:37 -0800 [thread overview]
Message-ID: <addb89bd-2c2a-43a9-8492-ca541b48de33@intel.com> (raw)
In-Reply-To: <fc965672-a30a-4f5a-98af-2cdab1f53153@linux.intel.com>
On 2/13/2024 01:34, Tvrtko Ursulin wrote:
> On 12/02/2024 21:23, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> The watchdog test reduces the watchdog timer from 20s to 1s and then
>> uses a 5s timeout waiting for the watchdog to do its stuff. This works
>> fine in general, but if an engine reset is required by a context that
>> is actually dead for real then a pre-emption timeout must be factored
>> in. For RCS/CCS engines, that timeout is 7.5 seconds by default. Thus,
>> the test timeout expires first and the test fails.
>>
>> Normally, the system is not so dead when running this test as to
>> require an engine reset. A simple pre-emption works fine for the
>> spinner contexts that is uses. However, there is a hardware workaround
>> coming which prevents context switches when both RCS and CCS are busy.
>>
>> So add an explicit override of the pre-emption timeout as well as the
>> watchdog timeout. That will allow the test to keep working after the
>> new w/a lands.
>>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> ---
>> tests/intel/gem_watchdog.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/tests/intel/gem_watchdog.c b/tests/intel/gem_watchdog.c
>> index 1e4c350214c0..c9dd0deb51aa 100644
>> --- a/tests/intel/gem_watchdog.c
>> +++ b/tests/intel/gem_watchdog.c
>> @@ -577,6 +577,16 @@ igt_main
>> i915 = drm_reopen_driver(i915); /* Apply modparam. */
>> ctx = intel_ctx_create_all_physical(i915);
>> +
>> + for_each_ctx_engine(i915, ctx, e) {
>> + /*
>> + * Context termination by watchdog may require an engine
>> reset. That only
>> + * occurs after a pre-emption attempt has expired. For
>> RCS/CCS engines,
>> + * the pre-emption timeout is longer than this test is
>> wanting to wait.
>> + * So reduce that timeout in addition to the watchdog
>> timeout itself.
>> + */
>> + gem_engine_property_printf(i915, e->name,
>> "preempt_timeout_ms", "%d", 640);
>> + }
>
> Restore at test exit for subsequent tests to be in a known environment?
IGT actually does the reverse. Part of the framework initialisation is
to forcibly reset all the sysfs parameters to the official defaults (as
exposed via the .default sysfs files). So in general, the tests don't
bother trying to preserve such values.
John.
>
> Regards,
>
> Tvrtko
>
>> }
>> igt_subtest_group {
next prev parent reply other threads:[~2024-02-16 1:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-12 21:23 [PATCH i-g-t] tests/intel/gem_watchdog: Reduced timeouts for worst case scenario John.C.Harrison
2024-02-12 23:35 ` ✓ Fi.CI.BAT: success for " Patchwork
2024-02-13 0:26 ` ✓ CI.xeBAT: " Patchwork
2024-02-13 2:57 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-02-13 9:34 ` [PATCH i-g-t] " Tvrtko Ursulin
2024-02-16 1:33 ` John Harrison [this message]
2024-02-19 9:53 ` Tvrtko Ursulin
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=addb89bd-2c2a-43a9-8492-ca541b48de33@intel.com \
--to=john.c.harrison@intel.com \
--cc=IGT-Dev@Lists.FreeDesktop.Org \
--cc=tvrtko.ursulin@linux.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