[Intel-gfx] [PATCH 01/19] drm/i915/perf: Fix OA filtering logic for GuC mode

[Umesh Nerlige Ramappa]

On Wed, Sep 14, 2022 at 04:13:41PM -0700, Umesh Nerlige Ramappa wrote:
>On Wed, Sep 14, 2022 at 03:26:15PM -0700, Umesh Nerlige Ramappa wrote:
>>On Tue, Sep 06, 2022 at 09:39:33PM +0300, Lionel Landwerlin wrote:
>>>On 06/09/2022 20:39, Umesh Nerlige Ramappa wrote:
>>>>On Tue, Sep 06, 2022 at 05:33:00PM +0300, Lionel Landwerlin wrote:
>>>>>On 23/08/2022 23:41, Umesh Nerlige Ramappa wrote:
>>>>>>With GuC mode of submission, GuC is in control of defining 
>>>>>>the context id field
>>>>>>that is part of the OA reports. To filter reports, UMD and 
>>>>>>KMD must know what sw
>>>>>>context id was chosen by GuC. There is not interface between 
>>>>>>KMD and GuC to
>>>>>>determine this, so read the upper-dword of EXECLIST_STATUS 
>>>>>>to filter/squash OA
>>>>>>reports for the specific context.
>>>>>>
>>>>>>Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa at intel.com>
>>>>>
>>>>>
>>>>>I assume you checked with GuC that this doesn't change as the 
>>>>>context is running?
>>>>
>>>>Correct.
>>>>
>>>>>
>>>>>With i915/execlist submission mode, we had to ask i915 to pin 
>>>>>the sw_id/ctx_id.
>>>>>
>>>>
>>>>From GuC perspective, the context id can change once KMD 
>>>>de-registers the context and that will not happen while the 
>>>>context is in use.
>>>>
>>>>Thanks,
>>>>Umesh
>>>
>>>
>>>Thanks Umesh,
>>>
>>>
>>>Maybe I should have been more precise in my question :
>>>
>>>
>>>Can the ID change while the i915-perf stream is opened?
>>>
>>>Because the ID not changing while the context is running makes sense.
>>>
>>>But since the number of available IDs is limited to 2k or 
>>>something on Gfx12, it's possible the GuC has to reuse IDs if too 
>>>many apps want to run during the period of time while i915-perf is 
>>>active and filtering.
>>>
>>
>>available guc ids are 64k with 4k reserved for multi-lrc, so GuC may 
>>have to reuse ids once 60k ids are used up.
>
>Spoke to the GuC team again and if there are a lot of contexts (> 60K) 
>running, there is a possibility of the context id being recycled. In 
>that case, the capture would be broken. I would track this as a 
>separate JIRA and follow up on a solution.
>
>From OA use case perspective, are we interested in monitoring just one 
>hardware context? If we make sure this context is not stolen, are we 
>good?
>

+ John

Based on John's inputs - if a context is pinned, then KMD does not steal 
it's id. It would just look for something else or wait for a context to 
be available (pin count 0 I believe).

Since we pin the context for the duration of the OA use case, we should 
be good here.

Thanks,
Umesh

>Thanks,
>Umesh
>
>>
>>Thanks,
>>Umesh
>>
>>>
>>>-Lionel
>>>
>>>
>>>>
>>>>>
>>>>>If that's not the case then filtering is broken.
>>>>>
>>>>>
>>>>>-Lionel
>>>>>
>>>>>