[Intel-gfx] [PATCH 2/5] drm/i915/perf: allow holding preemption on filtered ctx

[Chris Wilson]

Quoting Lionel Landwerlin (2019-05-24 10:28:16)
> On 21/05/2019 17:36, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-05-21 15:08:52)
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> index f263a8374273..2ad95977f7a8 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> @@ -2085,7 +2085,7 @@ static int gen9_emit_bb_start(struct i915_request *rq,
> >>          if (IS_ERR(cs))
> >>                  return PTR_ERR(cs);
> >>   
> >> -       *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
> >> +       *cs++ = MI_ARB_ON_OFF | rq->hw_context->arb_enable;
> > My prediction is that this will result in this context being reset due
> > to preemption timeouts and the context under profile being banned. Note
> > that preemption timeouts will be the primary means for hang detection
> > for endless batches.
> > -Chris
> >
> 
> Another thought :
> 
> What if we ran with the max priority?
> It would be fine to have the hangcheck preempt the workload (it's pretty 
> short and shouldn't affect perf counters from 3d/compute pipeline much) 
> as long as ensure nothing else runs.

It's certainly safer from the pov that we don't block preemption and so
don't incur forced resets. Not keen on the system being perturbed by the
act of observing it, and I still dislike the notion of permitting one
client to hog the GPU so easily. Makes me think of RT throttling, and
generally throwing out the absolute priority system (in exchange for
computed deadlines or something).
-Chris