Quoting Chris Wilson (2018-03-08 11:32:04) > Quoting Matt Roper (2018-03-06 23:46:59) > > There are cases where a system integrator may wish to raise/lower the > > priority of GPU workloads being submitted by specific OS process(es), > > independently of how the software self-classifies its own priority. > > Exposing "priority offset" as an i915-specific cgroup parameter will > > enable such system-level configuration. > > > > Normally GPU contexts start with a priority value of 0 > > (I915_CONTEXT_DEFAULT_PRIORITY) and then may be adjusted up/down from > > there via other mechanisms. We'd like to provide a system-level input > > to the priority decision that will be taken into consideration, even > > when userspace later attempts to set an absolute priority value via > > I915_CONTEXT_PARAM_PRIORITY. The priority offset introduced here > > provides a base value that will always be added to (or subtracted from) > > the software's self-assigned priority value. > > > > This patch makes priority offset a cgroup-specific value; contexts will > > be created with a priority offset based on the cgroup membership of the > > process creating the context at the time the context is created. Note > > that priority offset is assigned at context creation time; migrating a > > process to a different cgroup or changing the offset associated with a > > cgroup will only affect new context creation and will not alter the > > behavior of existing contexts previously created by the process. > > > > v2: > > - Rebase onto new cgroup_priv API > > - Use current instead of drm_file->pid to determine which process to > > lookup priority for. (Chris) > > - Don't forget to subtract priority offset in context_getparam ioctl to > > make it match setparam behavior. (Chris) > > > > Signed-off-by: Matt Roper <matthew.d.roper@xxxxxxxxx> > > For ctx->priority/ctx->priority_offset > Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> As a reminder, we do have the question of how to bound ctx->priority + ctx->priority_offset. Currently, outside of the user range is privileged space reserved for the kernel (both above and below). Now we can move those even further to accommodate multiple non-overlapping cgroups. We also have the presumption that only privileged processes can raise a priority, but I presume the cgroup property itself is protected. -Chris -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
