[0/3] Inherit GPU scheduling priority from process nice

Message

Tvrtko Ursulin April 5, 2022, 2:53 p.m. UTC

From: Tvrtko Ursulin <[e-mail]>

Current processing landscape seems to be more and more composed of pipelines
where computations are done on multiple hardware devices. Furthermore some of
the non-CPU devices, like in this case many GPUs supported by the i915 driver,
actually support priority based scheduling which is currently rather
inaccessible to the user (in terms of being able to control it from the
outside).

From these two statements a question arises on how to allow for a simple,
effective and consolidated user experience. In other words why user would not be
able to do something like:

 $ nice ffmmpeg ...transcode my videos...
 $ my-favourite-game

And have the nice hint apply to GPU parts of the transcode pipeline as well?

This would in fact follow the approach taken by kernel's block scheduler where
ionice is by default inherited from process nice.

This series implements the same idea by inheriting context creator and batch
buffer submitted nice value as context nice. To avoid influencing GPU scheduling
aware clients this is done only one for contexts where userspace hasn't
explicitly specified a non-default scheduling priority

With the series applied I simulated the scenario of a background GPU task
running simultaneously with an interactive client, varying the hog's nice value.
These were the results:

   GPU hog (nice) |   TRex fps    |   perf drop
   ---------------+---------------+------------
       no hog     |     48.9      |    - n/a -
          0       |     42.7      |     -13%
         10       |     47.9      |      -2%
        -10       |     29.0      |     -41%

As can be seen running the background GPU task re-niced can restore the
performance of the foreground task to almost the level when it is running alone
on the machine.

The approach is completely compatible with GuC and drm/scheduler since all
support at least low/normal/high priority levels with just the granularity of
available control differing. In other words with GuC scheduling there is no
difference between nice 5 and 10, both would map to low priority, but the
default case of positive or negative nice, versus nice 0, is still correctly
propagated to the firmware scheduler.

v2:
 * Moved notifier outside task_rq_lock.
 * Some improvements and restructuring on the i915 side of the series.

v3:
 * Dropped task nice notifier - inheriting nice on request submit time is good
   enough.

Tvrtko Ursulin (3):
  drm/i915: Make some recently added vfuncs use full scheduling
    attribute
  drm/i915: Inherit process nice for context scheduling priority
  drm/i915: Inherit submitter nice when scheduling requests

 drivers/gpu/drm/i915/gem/i915_gem_context.c      |  6 +++++-
 .../gpu/drm/i915/gt/intel_execlists_submission.c |  6 ++++--
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c    |  3 ++-
 drivers/gpu/drm/i915/i915_request.c              |  7 +++++--
 drivers/gpu/drm/i915/i915_request.h              |  5 +++++
 drivers/gpu/drm/i915/i915_scheduler.c            | 16 ++++++++++------
 drivers/gpu/drm/i915/i915_scheduler.h            | 14 ++++++++++++++
 drivers/gpu/drm/i915/i915_scheduler_types.h      | 12 ++++++++++--
 8 files changed, 55 insertions(+), 14 deletions(-)