[Intel-gfx] [PATCH v10 0/8] Per context dynamic (sub)slice power-gating

[Tvrtko Ursulin]

From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>

Updated series after continuing Lionel's work.

Userspace for the feature is the media-driver project on GitHub. Please see
https://github.com/intel/media-driver/pull/271/commits.

Headline changes:

 1.

  No more master allow/disallow sysfs switch. Feature is unconditionally
  enabled for Gen11 and on other platforms it requires CAP_SYS_ADMIN.

  *** To be discussed if this is a good idea or not. ***

 2.

  Two new patches due a) breaking out the global barrier, and b) fixing one
  GEM_BUG_ON regarding incorrent kernel context classification by i915_is_ggtt.


Otherwise please see individial patch change logs.

Main topic for the cover letter though is addressing the question of dynamic
slice re-configuration performance impact.

Introduction into this problem space is that changing the (sub)slice
configuration has a cost at context switch time in the order of tens of milli-
seconds. (It varies per Gen and with different slice count transitions.)

So the question is whether a malicious unprivileged workload can negatively
impact other clients. To try and answer this question I have extended gem_wsim
and creating some test workloads. (Note that my testing was done on a Gen9
system. Overall message could be the same on Gen11 but needs to be verified.)

First test was a simulated video playback client running in parallel with a
simulated game of both medium and high complexity (uses around 60% or 90% of the
render engine respectively, and 7% of the blitter engine). I had two flavours of
the playback client, one which runs normally and one which requests reduced
slice configuration. Both workloads are targetting to run at 60fps.

Second test is the same but against a heavier simulated game workload, the one
which uses around 90% of the render engine.

Results are achieved frames per second as observed from the game client:

                     No player  Normal player   SSEU enabled player
        Medium game     59.6        59.6               59.6
         Heavy game     59.7        58.4               58.1

Here we can see that the medium workload was not affected either by the normal
or SSEU player, while the heavy workload did see a performance hit. Both with
the video player running in parallel, and slighlty larger when the player was
SSEU enabled.

Second test is running a malicious client (or clients) in parallel to the same
simulated game workloads. These clients try to trigger many context switches by
using multiple contexts with dependencies set up so request coalescing is
defeated as much as possible.

I tested both with normal and SSEU enabled malicious clients:

                     DoS client   SSEU DoS client
        Medium game     59.5           59.6
         Heavy game     57.8           55.4

For here we can see a similar picture as with the first test. Medium game client
is not affected by either DoS client, while the heavy game client is, more so
with the SSEU enabled attacker.

>From both tests I think the conclusion is that dynamic SSEU switching does
increase the magnitude of performance loss, especially with over-subscribed
engines, due cost being proportional to context switch frequency.

Likelyhood is that it slightly lowers the utilization level at which this starts
to happen, but does not introduce a completely new vector of attack - that is -
where it was possible to DoS a system from an unprivileged client, it still is.
In both cases (SSEU enabled or not), a malicious client has the option to grind
the system to a halt, albeit it may need fewer submission threads to do so when
it is SSEU enabled.

Chris Wilson (3):
  drm/i915: Program RPCS for Broadwell
  drm/i915: Record the sseu configuration per-context & engine
  drm/i915: Expose RPCS (SSEU) configuration to userspace

Lionel Landwerlin (3):
  drm/i915/perf: simplify configure all context function
  drm/i915/perf: reuse intel_lrc ctx regs macro
  drm/i915/perf: lock powergating configuration to default when active

Tvrtko Ursulin (2):
  drm/i915: Add global barrier support
  drm/i915: Explicitly mark Global GTT address spaces

 drivers/gpu/drm/i915/i915_drv.h         |  56 +++++++
 drivers/gpu/drm/i915/i915_gem.c         |   2 +
 drivers/gpu/drm/i915/i915_gem_context.c | 189 +++++++++++++++++++++++-
 drivers/gpu/drm/i915/i915_gem_context.h |   4 +
 drivers/gpu/drm/i915/i915_gem_gtt.c     |   2 +
 drivers/gpu/drm/i915/i915_gem_gtt.h     |   5 +-
 drivers/gpu/drm/i915/i915_perf.c        |  68 +++++----
 drivers/gpu/drm/i915/i915_request.c     |  16 ++
 drivers/gpu/drm/i915/i915_request.h     |  10 ++
 drivers/gpu/drm/i915/intel_lrc.c        |  87 ++++++++---
 drivers/gpu/drm/i915/intel_lrc.h        |   3 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |   4 +
 include/uapi/drm/i915_drm.h             |  43 ++++++
 13 files changed, 439 insertions(+), 50 deletions(-)

-- 
2.17.1