[PATCH v3 0/6] DRM/i915 cgroup integration

[Matt Roper]

This is the third iteration of the work previously posted here:
  (v1) https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
  (v2) https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html

The high level goal of this work is to allow non-cgroup-controller parts
of the kernel (e.g., device drivers) to register their own private
policy data for specific cgroups.  That mechanism is then made use of in
the i915 graphics driver to allow GPU priority to be assigned according
to the cgroup membership of the owning process.  Please see the v1 cover
letter linked above for a more in-depth explanation and justification.

Key changes in v3 of this series:

 * The cgroup core interfaces have been redesigned as suggested by
   Tejun.  The cgroup core now supports the following:

        void cgroup_priv_install(struct cgroup *cgrp,
                                 struct cgroup_priv *priv);
        struct cgroup_priv *cgroup_priv_lookup(struct cgroup *cgrp,
                                               const void *key);
        void cgroup_priv_free(struct cgroup *cgrp, const void *key);

 * Consumers of this interface may want to test the filesystem
   permissions of a cgroup to decide whether to allow custom syscalls or
   ioctls to operate on a cgroup's private data.  A new
   cgroup_permission(cgrp_fd, mask) function has been added to make this
   easier.

 * The i915 code looks up cgroup private data for 'current' rather than
   drm_file->pid to account for the device handle passing done by DRI3
   (i.e., the process that opened the device filehandle isn't
   necessarily the same process issuing ioctl's on it).

 * Other minor updates/changes based on feedback from Chris Wilson and
   Tejun Heo.


One open question on the i915 side of this work is whether we need to
limit the "priority offset" that can be assigned via cgroup (and if so,
what it should be limited to).  At the moment we make the assumption
that cgroup-based priority will be assigned by a privileged system
administrator / system integrator, so we accept any integer value they
choose to assign to the priority, even if it doesn't make sense.

As noted on previous iterations, the i915 userspace consumer for the
ioctl here is a simple i-g-t tool that will be sent shortly as a
followup on the intel-gfx list.  The tool itself is pretty trivial, but
that's intetional; the "real" userspace consumer of this work would
usually be something like a sysv-init script or systemd recipe that
would call that simple tool in an appropriate way to accomplish the
desired policy for a specific system.


Matt Roper (6):
  cgroup: Allow registration and lookup of cgroup private data
  cgroup: Introduce task_get_dfl_cgroup()
  cgroup: Introduce cgroup_permission()
  drm/i915: cgroup integration
  drm/i915: Introduce 'priority offset' for GPU contexts
  drm/i915: Add context priority & priority offset to debugfs (v2)

 drivers/gpu/drm/i915/Makefile           |   1 +
 drivers/gpu/drm/i915/i915_cgroup.c      | 214 ++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/i915_debugfs.c     |   3 +
 drivers/gpu/drm/i915/i915_drv.c         |   5 +
 drivers/gpu/drm/i915/i915_drv.h         |  25 ++++
 drivers/gpu/drm/i915/i915_gem_context.c |   7 +-
 drivers/gpu/drm/i915/i915_gem_context.h |   9 ++
 include/linux/cgroup-defs.h             |  38 ++++++
 include/linux/cgroup.h                  | 102 +++++++++++++++
 include/uapi/drm/i915_drm.h             |  13 ++
 kernel/cgroup/cgroup.c                  |  56 +++++++++
 11 files changed, 470 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_cgroup.c

-- 
2.14.3