[Intel-gfx] [PATCH v6 09/11] drm/i915/perf: allow holding preemption on filtered ctx

[Lionel Landwerlin]

On 01/07/2019 17:37, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2019-07-01 13:10:53)
>> On 01/07/2019 15:03, Chris Wilson wrote:
>>> Quoting Lionel Landwerlin (2019-07-01 12:34:35)
>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>>> index f92bace9caff..012d6d7f54e2 100644
>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>>>> @@ -2104,6 +2104,14 @@ static int eb_oa_config(struct i915_execbuffer *eb)
>>>>           if (err)
>>>>                   return err;
>>>>    
>>>> +       /*
>>>> +        * If the perf stream was opened with hold preemption, flag the
>>>> +        * request properly so that the priority of the request is bumped once
>>>> +        * it reaches the execlist ports.
>>>> +        */
>>>> +       if (eb->i915->perf.oa.exclusive_stream->hold_preemption)
>>>> +               eb->request->flags |= I915_REQUEST_FLAGS_PERF;
>>> Just to reassure myself that this is the behaviour you:
>>>
>>> If the exclusive_stream is changed before the request is executed, it is
>>> likely that we no longer notice the earlier preemption-protection. This
>>> should not matter because the listener is no longer interested in those
>>> events?
>>> -Chris
>>>
>> Yeah, dropping the perf stream before your queries complete and you're
>> in undefined behavior territory.
> Then this should do what you want, and if I break it in future, I have
> to fix it ;)
>
> Hmm, this definitely merits some selftest/igt as I am very liable to
> break it.
>
> Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
> -Chris
>

I had an IGT test that used a spinning batch for a couple of seconds 
(same trick as the noa wait patch) and verified that no other context 
would come up in the OA buffer.

This might need allowing the preempt context or whatever is used for 
hang checks.


-Lionel