[Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)
chris at chris-wilson.co.uk
Thu Mar 8 18:55:34 UTC 2018
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.
> 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?
More information about the Intel-gfx