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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
