Re: [Intel-gfx] [PATCH 5/6] drm/i915: Track per drm client engine class busyness

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 07/02/2020 17:02, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2020-02-07 16:49:17)
>>
>> On 07/02/2020 16:33, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2020-02-07 16:13:30)
>>>>    static inline void
>>>> -__intel_context_stats_start(struct intel_context *ce, ktime_t now)
>>>> +__intel_context_stats_start(struct intel_context *ce,
>>>> +                           struct intel_engine_cs *engine,
>>>> +                           ktime_t now)
>>>>    {
>>>>           struct intel_context_stats *stats = &ce->stats;
>>>> -
>>>> -       if (!stats->active) {
>>>> -               stats->start = now;
>>>> -               stats->active = true;
>>>> +       struct i915_gem_context *ctx;
>>>> +
>>>> +       if (stats->active)
>>>> +               return;
>>>> +
>>>> +       stats->start = now;
>>>> +       stats->active = true;
>>>> +
>>>> +       rcu_read_lock();
>>>> +       ctx = rcu_dereference(ce->gem_context);
>>>> +       if (ctx && ctx->client) {
>>>
>>> I'd rather avoid having to dig into the GEM context down here next to
>>> the HW.
>>>
>>> First thought would be to keep the stats local on the intel_context and
>>> for the client to chase collate them when the user reads the fd.
>>>
>>> Hmm, didn't you structure it like so earlier? What made you change your
>>> mind?
>>
>> Yes, it's in the cover letter - we must not have disappearing
>> contributions - client can submit from one context for a bit, close it,
>> and oops usage history lost.
> 
> If only we had a mechanism for accumulating contributions from stale
> engines and then from stale contests?
>   
>> ce->drm_client? :)
> 
> Yeah that is equally icky for swimming upstream.
> 
> Ok, I have an idea for capturing the contributions at close rather than
> having to do global accumulations at runtime.

It's certainly possible by accumulating over context runtimes when they 
are closed and adding to active runtime at readout. I contemplated that 
solution as well.

Regards,

Tvrtko


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx