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@xxxxxxxxxxxxxxxxxxxxx/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 -- 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
