[Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

[Chris Wilson]

Quoting Chris Wilson (2018-03-08 18:48:51)
> Quoting Matt Roper (2018-03-08 18:22:06)
> >  * Option 2:  Allow priority offset to be set in a much larger range
> >    (e.g., [SHRT_MIN+1023,SHRT_MAX-1023]).  This allows cgroups to have
> >    effective priority ranges that don't overlap.  cgroup ranges can also
> >    be intentionally set above I915_PRIORITY_DISPLAY to allow us to
> >    define classes of applications whose work is more important than
> >    maintaining a stable framerate on the display.  We'd also probably
> >    need to shift the kernel idle context down to something like INT_MIN
> >    instead of using -1024.
> 
> INT_MIN+1 just to be awkward. (INT_MIN is I915_PRIORITY_INVALID.)
> 
> Something to bear in mind is that I want to reserve the low 8 bits of
> ctx->priority for internal use (heuristic adjustments by the scheduler).
> Can shrink that to say 3 bits in the current scheme.
> 
> 3bits for internal adjustment
> 20bits for user priority.
> 8bits for cgroup offset.
> signbit.
> 
> Nothing prohibits us from moving to 64b if required. But 32b should be
> enough range for plenty of clients and cgroups, imo. Reducing cgroup
> offset to 6 bits would be nice :)

Forgot to comment on the policy decision of I915_PRIORITY_DISPLAY.
It's naughty that it's a magic constant that isn't exposed to the
sysadmin, so I would still set it to the maximum priority possible under
the extended scheme (i.e. INT_MAX), but allow for it to be adjusted.
I915_SETPARAM *shivers* Maybe that's a topic for cgroup as well if we can
associate the pageflip with a process and find its interactivity settings.

Can I expose just about any random policy decision through cgroup?
-Chris