[Intel-gfx] [RFC 8/8] drm/i915: Expose per-engine client busyness

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-12-19 18:00:19)
> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> 
> Expose per-client and per-engine busyness under the previously added sysfs
> client root.
> 
> The new files are one per-engine instance and located under the 'busy'
> directory. Each contains a monotonically increasing nano-second resolution
> times each client's jobs were executing on the GPU.
> 
> This enables userspace to create a top-like tool for GPU utilization:
> 
> ==========================================================================
> intel-gpu-top -  935/ 935 MHz;    0% RC6; 14.73 Watts;     1097 irqs/s
> 
>       IMC reads:     1401 MiB/s
>      IMC writes:        4 MiB/s
> 
>           ENGINE      BUSY                                 MI_SEMA MI_WAIT
>      Render/3D/0   63.73% |███████████████████           |      3%      0%
>        Blitter/0    9.53% |██▊                           |      6%      0%
>          Video/0   39.32% |███████████▊                  |     16%      0%
>          Video/1   15.62% |████▋                         |      0%      0%
>   VideoEnhance/0    0.00% |                              |      0%      0%
> 
>   PID            NAME     RCS          BCS          VCS         VECS
>  4084        gem_wsim |█████▌     ||█          ||           ||           |
>  4086        gem_wsim |█▌         ||           ||███        ||           |
> ==========================================================================
> 
> v2: Use intel_context_engine_get_busy_time.
> v3: New directory structure.
> v4: Rebase.
> v5: sysfs_attr_init.
> v6: Small tidy in i915_gem_add_client.
> v7: Rebase to be engine class based.
> v8:
>  * Always enable stats.
>  * Walk all client contexts.
> 
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>

Other than splitting it out into i915_drm_client.c (et al). It
worksforme.

However, it's about as useful as top, but without any means to
kill/stop/reprioritise clients :(

To give me actionable data, do we not need more of a perf interface
where events are sent for client start/stop so that observers can
record the context utilisation within their sample periods? I'm thinking
of the "perf stat wsim..." use case where it gives me a breakdown of
each workload.
-Chris