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

Lionel Landwerlin lionel.g.landwerlin at intel.com
Tue May 21 17:52:16 UTC 2019


On 21/05/2019 18:17, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2019-05-21 17:50:30)
>> 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
>> Thanks,
>>
>> One question : how is that dealt with with compute workloads at the moment?
>> I though those where still not fully preemptable.
> Not blocking is the condition under which they get to use endless...
> compute jobs are preemptible from gen9 afaik, gen8 was problematic and so
> disabled.
>   
>> I need to rework this with a more "software" approach holding on preemption.
>> Adding a condition in intel_lrc.c need_preempt() looks like the right
>> direction?
> Even less if that is our means of hangcheck.
> -Chris
>

Can we differentiate between a hangcheck & a high priority request?

If I remember correctly, we can set the hangcheck timeout somewhere in /sys.

I think it's fine to ban the context doing a perf query if it's taking 
too long.


If a user runs into that scenario we can tell them to increase the timeout.


-Lionel



More information about the Intel-gfx mailing list