[Intel-gfx] [PATCH 19/24] drm/i915/scheduler: Support user-defined priorities
Jason Ekstrand
jason at jlekstrand.net
Wed Aug 2 21:55:19 UTC 2017
On Thu, May 18, 2017 at 2:46 AM, Chris Wilson <chris at chris-wilson.co.uk>
wrote:
> Use a priority stored in the context as the initial value when
> submitting a request. This allows us to change the default priority on a
> per-context basis, allowing different contexts to be favoured with GPU
> time at the expense of lower importance work. The user can adjust the
> context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
> values being higher priority (they will be serviced earlier, after their
> dependencies have been resolved). Any prerequisite work for an execbuf
> will have its priority raised to match the new request as required.
>
> Normal users can specify any value in the range of -1023 to 0 [default],
> i.e. they can reduce the priority of their workloads (and temporarily
> boost it back to normal if so desired).
>
> Privileged users can specify any value in the range of -1023 to 1023,
> [default is 0], i.e. they can raise their priority above all overs and
> so potentially starve the system.
>
How is "priviledged" defined? These days, X11 and/or your Wayland
compositor run as the logged in user. One thought (thanks to Rafael) would
be DRM master on the current VT. Also, is there some mechanism whereby a
"priviledged" app can make another app "priviledged"? I.e. X11 making your
compositor privileged.
> Note that the existing schedulers are not fair, nor load balancing, the
> execution is strictly by priority on a first-come, first-served basis,
> and the driver may choose to boost some requests above the range
> available to users.
>
> This priority was originally based around nice(2), but evolved to allow
> clients to adjust their priority within a small range, and allow for a
> privileged high priority range.
>
> For example, this can be used to implement EGL_IMG_context_priority
> https://www.khronos.org/registry/egl/extensions/IMG/
> EGL_IMG_context_priority.txt
>
> EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
> the context to be created. This attribute is a hint, as an
> implementation may not support multiple contexts at some
> priority levels and system policy may limit access to high
> priority contexts to appropriate system privilege level. The
> default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
> EGL_CONTEXT_PRIORITY_MEDIUM_IMG."
>
> so we can map
>
> PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
> PRIORITY_MED -> 0 [default]
> PRIORITY_LOW -> -1023
>
> They also map onto the priorities used by VkQueue (and a VkQueue is
> essentially a timeline, our i915_gem_context under full-ppgtt).
>
Not really. VkQueue priorities are a long and complicated story and were
*not* well thought-out in the API. Many hours of meetings have been wasted
trying to figure out what they mean. Whey they *don't* mean is a global
context priority.
> v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/
> v3: Report min/max user priorities as defines in the uapi, and rebase
> internal priorities on the exposed values.
>
> Testcase: igt/gem_exec_schedule
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 23 +++++++++++++++++++++++
> drivers/gpu/drm/i915/i915_gem_request.h | 11 ++++++++---
> include/uapi/drm/i915_drm.h | 9 ++++++++-
> 3 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index c62e17a68f5b..0735d624ef07 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -1038,6 +1038,9 @@ int i915_gem_context_getparam_ioctl(struct
> drm_device *dev, void *data,
> case I915_CONTEXT_PARAM_BANNABLE:
> args->value = i915_gem_context_is_bannable(ctx);
> break;
> + case I915_CONTEXT_PARAM_PRIORITY:
> + args->value = ctx->priority;
> + break;
> default:
> ret = -EINVAL;
> break;
> @@ -1095,6 +1098,26 @@ int i915_gem_context_setparam_ioctl(struct
> drm_device *dev, void *data,
> else
> i915_gem_context_clear_bannable(ctx);
> break;
> +
> + case I915_CONTEXT_PARAM_PRIORITY:
> + {
> + int priority = args->value;
> +
> + if (args->size)
> + ret = -EINVAL;
> + else if (!to_i915(dev)->engine[RCS]->schedule)
> + ret = -ENODEV;
> + else if (priority > I915_CONTEXT_MAX_USER_PRIORITY
> ||
> + priority < I915_CONTEXT_MIN_USER_
> PRIORITY)
> + ret = -EINVAL;
> + else if (priority > I915_CONTEXT_DEFAULT_PRIORITY
> &&
> + !capable(CAP_SYS_NICE))
> + ret = -EPERM;
> + else
> + ctx->priority = priority;
> + }
> + break;
> +
> default:
> ret = -EINVAL;
> break;
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.h
> b/drivers/gpu/drm/i915/i915_gem_request.h
> index 7b7c84369d78..d34d8adba9e9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.h
> +++ b/drivers/gpu/drm/i915/i915_gem_request.h
> @@ -30,6 +30,8 @@
> #include "i915_gem.h"
> #include "i915_sw_fence.h"
>
> +#include <uapi/drm/i915_drm.h>
> +
> struct drm_file;
> struct drm_i915_gem_object;
> struct drm_i915_gem_request;
> @@ -69,9 +71,12 @@ struct i915_priotree {
> struct list_head waiters_list; /* those after us, they depend upon
> us */
> struct list_head link;
> int priority;
> -#define I915_PRIORITY_MAX 1024
> -#define I915_PRIORITY_NORMAL 0
> -#define I915_PRIORITY_MIN (-I915_PRIORITY_MAX)
> +};
> +
> +enum {
> + I915_PRIORITY_MIN = I915_CONTEXT_MIN_USER_PRIORITY - 1,
> + I915_PRIORITY_NORMAL = I915_CONTEXT_DEFAULT_PRIORITY,
> + I915_PRIORITY_MAX = I915_CONTEXT_MAX_USER_PRIORITY + 1,
> };
>
> struct i915_gem_capture_list {
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 4adf3e5f5c71..34ee011f08ac 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -393,8 +393,11 @@ typedef struct drm_i915_irq_wait {
> #define I915_PARAM_MIN_EU_IN_POOL 39
> #define I915_PARAM_MMAP_GTT_VERSION 40
>
> -/* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
> +/*
> + * Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
> * priorities and the driver will attempt to execute batches in priority
> order.
> + * The initial priority for each batch is supplied by the context and is
> + * controlled via I915_CONTEXT_PARAM_PRIORITY.
> */
> #define I915_PARAM_HAS_SCHEDULER 41
> #define I915_PARAM_HUC_STATUS 42
> @@ -1320,6 +1323,10 @@ struct drm_i915_gem_context_param {
> #define I915_CONTEXT_PARAM_GTT_SIZE 0x3
> #define I915_CONTEXT_PARAM_NO_ERROR_CAPTURE 0x4
> #define I915_CONTEXT_PARAM_BANNABLE 0x5
> +#define I915_CONTEXT_PARAM_PRIORITY 0x6
> +#define I915_CONTEXT_MAX_USER_PRIORITY 1023 /* inclusive */
> +#define I915_CONTEXT_DEFAULT_PRIORITY 0
> +#define I915_CONTEXT_MIN_USER_PRIORITY -1023 /* inclusive */
> __u64 value;
> };
>
> --
> 2.11.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20170802/b782faf7/attachment-0001.html>
More information about the Intel-gfx
mailing list