All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Harrison <john.c.harrison@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	<Intel-GFX@Lists.FreeDesktop.Org>
Cc: DRI-Devel@Lists.FreeDesktop.Org
Subject: Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Make the heartbeat play nice with long pre-emption timeouts
Date: Thu, 29 Sep 2022 09:21:56 -0700	[thread overview]
Message-ID: <ae042c9d-f6f1-2ecd-e23a-7d6994c97151@intel.com> (raw)
In-Reply-To: <a2c2cddf-009b-a2e0-2af2-6f1553c59cbc@linux.intel.com>

On 9/29/2022 00:42, Tvrtko Ursulin wrote:
> On 29/09/2022 03:18, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> Compute workloads are inherently not pre-emptible for long periods on
>> current hardware. As a workaround for this, the pre-emption timeout
>> for compute capable engines was disabled. This is undesirable with GuC
>> submission as it prevents per engine reset of hung contexts. Hence the
>> next patch will re-enable the timeout but bumped up by an order of
>> magnitude.
>>
>> However, the heartbeat might not respect that. Depending upon current
>> activity, a pre-emption to the heartbeat pulse might not even be
>> attempted until the last heartbeat period. Which means that only one
>> period is granted for the pre-emption to occur. With the aforesaid
>> bump, the pre-emption timeout could be significantly larger than this
>> heartbeat period.
>>
>> So adjust the heartbeat code to take the pre-emption timeout into
>> account. When it reaches the final (high priority) period, it now
>> ensures the delay before hitting reset is bigger than the pre-emption
>> timeout.
>>
>> v2: Fix for selftests which adjust the heartbeat period manually.
>>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> ---
>>   .../gpu/drm/i915/gt/intel_engine_heartbeat.c  | 19 +++++++++++++++++++
>>   1 file changed, 19 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c 
>> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
>> index a3698f611f457..823a790a0e2ae 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
>> @@ -22,9 +22,28 @@
>>     static bool next_heartbeat(struct intel_engine_cs *engine)
>>   {
>> +    struct i915_request *rq;
>>       long delay;
>>         delay = READ_ONCE(engine->props.heartbeat_interval_ms);
>> +
>> +    rq = engine->heartbeat.systole;
>> +
>> +    if (rq && rq->sched.attr.priority >= I915_PRIORITY_BARRIER &&
>> +        delay == engine->defaults.heartbeat_interval_ms) {
>
> Maybe I forgot but what is the reason for the check against the 
> default heartbeat interval?
That's the 'v2: fix for selftests that manually adjust the heartbeat'. 
If something (or someone) has explicitly set an override of the 
heartbeat then it has to be assumed that they know what they are doing, 
and if things don't work any more that's their problem. But if we don't 
respect their override then they won't get the timings they expect and 
the selftest will fail.

John.

>
> Regards,
>
> Tvrtko
>
>> +        long longer;
>> +
>> +        /*
>> +         * The final try is at the highest priority possible. Up 
>> until now
>> +         * a pre-emption might not even have been attempted. So make 
>> sure
>> +         * this last attempt allows enough time for a pre-emption to 
>> occur.
>> +         */
>> +        longer = READ_ONCE(engine->props.preempt_timeout_ms) * 2;
>> +        longer = intel_clamp_heartbeat_interval_ms(engine, longer);
>> +        if (longer > delay)
>> +            delay = longer;
>> +    }
>> +
>>       if (!delay)
>>           return false;


  reply	other threads:[~2022-09-29 16:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29  2:18 [PATCH v4 0/4] Improve anti-pre-emption w/a for compute workloads John.C.Harrison
2022-09-29  2:18 ` [Intel-gfx] " John.C.Harrison
2022-09-29  2:18 ` [PATCH v4 1/4] drm/i915/guc: Limit scheduling properties to avoid overflow John.C.Harrison
2022-09-29  2:18   ` [Intel-gfx] " John.C.Harrison
2022-09-29  7:39   ` Tvrtko Ursulin
2022-09-29  2:18 ` [PATCH v4 2/4] drm/i915: Fix compute pre-emption w/a to apply to compute engines John.C.Harrison
2022-09-29  2:18   ` [Intel-gfx] " John.C.Harrison
2022-09-29  2:18 ` [PATCH v4 3/4] drm/i915: Make the heartbeat play nice with long pre-emption timeouts John.C.Harrison
2022-09-29  2:18   ` [Intel-gfx] " John.C.Harrison
2022-09-29  7:42   ` Tvrtko Ursulin
2022-09-29 16:21     ` John Harrison [this message]
2022-09-30  9:22       ` Tvrtko Ursulin
2022-09-30 17:44         ` John Harrison
2022-10-03  7:53           ` Tvrtko Ursulin
2022-10-03 12:00             ` Tvrtko Ursulin
2022-10-05 18:48               ` John Harrison
2022-10-06 10:03                 ` Tvrtko Ursulin
2022-09-29  2:18 ` [PATCH v4 4/4] drm/i915: Improve long running compute w/a for GuC submission John.C.Harrison
2022-09-29  2:18   ` [Intel-gfx] " John.C.Harrison
2022-09-29  7:44   ` Tvrtko Ursulin
2022-09-29  2:33 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Improve anti-pre-emption w/a for compute workloads (rev7) Patchwork
2022-09-29  2:33 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-09-29  2:53 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-09-30  2:28 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

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=ae042c9d-f6f1-2ecd-e23a-7d6994c97151@intel.com \
    --to=john.c.harrison@intel.com \
    --cc=DRI-Devel@Lists.FreeDesktop.Org \
    --cc=Intel-GFX@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 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.