Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff McGee <jeff.mcgee@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, ben@bwidawsk.net,
	kalyan.kondapally@intel.com
Subject: Re: [RFC 0/8] Force preemption
Date: Thu, 22 Mar 2018 07:34:58 -0700	[thread overview]
Message-ID: <20180322143458.GG19343@jeffdesk> (raw)
In-Reply-To: <152171088042.23562.11055705672254289437@mail.alporthouse.com>

On Thu, Mar 22, 2018 at 09:28:00AM +0000, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-03-22 09:22:55)
> > 
> > On 21/03/2018 17:26, jeff.mcgee@intel.com wrote:
> > > From: Jeff McGee <jeff.mcgee@intel.com>
> > > 
> > > Force preemption uses engine reset to enforce a limit on the time
> > > that a request targeted for preemption can block. This feature is
> > > a requirement in automotive systems where the GPU may be shared by
> > > clients of critically high priority and clients of low priority that
> > > may not have been curated to be preemption friendly. There may be
> > > more general applications of this feature. I'm sharing as an RFC to
> > > stimulate that discussion and also to get any technical feedback
> > > that I can before submitting to the product kernel that needs this.
> > > I have developed the patches for ease of rebase, given that this is
> > > for the moment considered a non-upstreamable feature. It would be
> > > possible to refactor hangcheck to fully incorporate force preemption
> > > as another tier of patience (or impatience) with the running request.
> > 
> > Sorry if it was mentioned elsewhere and I missed it - but does this work 
> > only with stateless clients - or in other words, what would happen to 
> > stateful clients which would be force preempted? Or the answer is we 
> > don't care since they are misbehaving?
> 
> They get notified of being guilty for causing a gpu reset; three strikes
> and they are out (banned from using the gpu) using the current rules.
> This is a very blunt hammer that requires the rest of the system to be
> robust; one might argue time spent making the system robust would be
> better served making sure that the timer never expired in the first place
> thereby eliminating the need for a forced gpu reset.
> -Chris

Yes, for simplication the policy applied to force preempted contexts
is the same as for hanging contexts. It is known that this feature
should not be required in a fully curated system. It's a requirement
if end user will be alllowed to install 3rd party apps to run in the
non-critical domain.
-Jeff
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-03-22 14:49 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 17:26 [RFC 0/8] Force preemption jeff.mcgee
2018-03-21 17:26 ` [RFC 1/8] drm/i915/execlists: Refactor out complete_preempt_context() jeff.mcgee
2018-03-21 17:26 ` [RFC 2/8] drm/i915: Add control flags to i915_handle_error() jeff.mcgee
2018-03-21 17:26 ` [RFC 3/8] drm/i915: Move engine reset prepare/finish to backends jeff.mcgee
2018-03-21 17:26 ` [RFC 4/8] drm/i915: Split execlists/guc reset prepartions jeff.mcgee
2018-03-21 17:26 ` [RFC 5/8] drm/i915/execlists: Flush pending preemption events during reset jeff.mcgee
2018-03-21 17:26 ` [RFC 6/8] drm/i915: Fix loop on CSB processing jeff.mcgee
2018-03-21 17:33   ` Jeff McGee
2018-03-21 18:06     ` Chris Wilson
2018-03-21 18:29       ` Jeff McGee
2018-03-21 19:04         ` Chris Wilson
2018-03-21 17:26 ` [RFC 7/8] drm/i915: Skip CSB processing on invalid CSB tail jeff.mcgee
2018-03-21 17:31   ` Jeff McGee
2018-03-21 18:12     ` Chris Wilson
2018-03-21 19:06       ` Chris Wilson
2018-03-21 17:26 ` [RFC 8/8] drm/i915: Force preemption to complete via engine reset jeff.mcgee
2018-03-21 18:50 ` ✗ Fi.CI.BAT: failure for Force preemption (rev2) Patchwork
2018-03-22  9:22 ` [RFC 0/8] Force preemption Tvrtko Ursulin
2018-03-22  9:28   ` Chris Wilson
2018-03-22 14:34     ` Jeff McGee [this message]
2018-03-22 15:35       ` Chris Wilson
2018-03-22 15:44         ` Jeff McGee
2018-03-22 15:57       ` Tvrtko Ursulin
2018-03-22 16:01         ` Jeff McGee
2018-03-22 17:41           ` Tvrtko Ursulin
2018-03-22 19:08             ` Jeff McGee
2018-03-22 19:59               ` Bloomfield, Jon
2018-03-23 13:20                 ` Joonas Lahtinen
2018-03-23 13:37                   ` Chris Wilson
  -- strict thread matches above, loose matches on Subject: below --
2018-03-16 18:30 jeff.mcgee
2018-03-16 20:53 ` Chris Wilson
2018-03-16 21:03   ` Chris Wilson
2018-03-16 22:34 ` Chris Wilson

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=20180322143458.GG19343@jeffdesk \
    --to=jeff.mcgee@intel.com \
    --cc=ben@bwidawsk.net \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kalyan.kondapally@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