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