[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