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

[Matt Roper]

On Thu, Mar 08, 2018 at 06:55:34PM +0000, Chris Wilson wrote:
> 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

If the policy applies to a cgroup of processes, then we can deal with
pretty much any kind of policy as long as we stick to the driver ioctl
approach in this series.  E.g., we could add a cgroup setting "eligible
for display boost" so that only specific processes are eligible for a
display boost.

If we want to control a single overall system value (e.g., "set the
display boost fixed value") we could technically do that by having such
parameters set on the v2 hierarchy's root cgroup, but that seems a bit
counterintuitive and I'm not sure if there's a benefit to doing so.
Using a more general interface like I915_SETPARAM or sysfs or something
seems more appropriate in that case.


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795