From: Matt Roper <matthew.d.roper@intel.com>
To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
cgroups@vger.kernel.org
Subject: [PATCH RFC v2 0/7] DRM management via cgroups
Date: Thu, 1 Feb 2018 11:53:08 -0800 [thread overview]
Message-ID: <20180201195315.4956-1-matthew.d.roper@intel.com> (raw)
This is a second iteration of the patches originally posted here:
https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
Please see the original cover letter to understand the general goal and
justification for this work.
This series makes the following important changes to the design from
the first version:
* The "cgroup helper library" has been removed from the DRM core; the
early patches of this series introduce an enhancement to the cgroup
subsystem itself which will grant drivers the ability to save/restore
their own driver-specific data structures associated with individual
cgroups. Drivers may subclass the cgroup_driver_data structure to
store any kind of per-cgroup data they want, not just integer
key/value pairs as the helper library from version 1 of this series
did. Moving this functionality directly into cgroups will also allow
other parts of the kernel to potentially benefit from this
functionality, not just DRM drivers.
* The general graphics-specific ioctl to set cgroup parameters has
moved from the DRM core to i915. This was pretty much an arbitrary
choice I made while re-writing the new version of the series; I don't
have a strong opinion over whether the ioctl goes in the DRM core or
stays i915-specific. I'd appreciate feedback from other driver teams
as to whether they anticipate cgroup integration being useful for
their drivers and use cases (e.g., for controlling things like GPU
memory usage, priority settings, etc.). I'll move the ioctl back to
the DRM core in the next iteration if there's interest from other
driver teams.
* The i915-specific usage of this functionality is to adjust GPU
priority for groups of processes. Based on Chris' feedback, I've
made this control a "priority offset" rather than just a starting
priority, so that the change applied by cgroup will be added to the
explicitly-set context priority rather than being overwritten by it.
At the moment i915 still just assigns the priority offset one time at
context creation and doesn't alter it if the process migrates between
cgroups at runtime or if the cgroup has a new value assigned to it;
such changes only affect the priority offset of new contexts created
by a process. I'm open to feedback on whether we should also make
cgroup changes affect existing GPU context(s) from a process.
As noted on v1 of my patch series, cgroup control of graphics driver
concepts is expected to be done mostly during system startup (e.g., a
sysv-init script or a systemd recipe written by a system integrator and
custom to their own setup), so we don't really need a terribly
complicated userspace, just a simple tool that can be called by
appropriate scripts/recipes to set the desired policy. I've re-written
the tool from v1 of the patch series as an i-g-t tool this time and will
send it as followup email shortly.
Still on my TODO list (once I gather some more general feedback and move
out of the early RFC stage):
* Document this more fully in both the cgroups documentation and the
i915 kerneldoc.
* Write some i-g-t tests to exercise the ioctl and all the corner
cases.
Matt Roper (7):
cgroup: Allow drivers to store data associated with a cgroup
kernfs: Export kernfs_get_inode
cgroup: Add interface to allow drivers to lookup process cgroup
membership
drm: Add helper to obtain cgroup of drm_file's owning process
drm/i915: cgroup integration
drm/i915: Introduce 'priority offset' for GPU contexts
drm/i915: Add context priority & priority offset to debugfs
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_cgroup.c | 180 ++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_debugfs.c | 3 +
drivers/gpu/drm/i915/i915_drv.c | 7 ++
drivers/gpu/drm/i915/i915_drv.h | 31 ++++++
drivers/gpu/drm/i915/i915_gem_context.c | 6 +-
drivers/gpu/drm/i915/i915_gem_context.h | 9 ++
fs/kernfs/inode.c | 1 +
include/drm/drm_file.h | 20 ++++
include/linux/cgroup-defs.h | 37 +++++++
include/linux/cgroup.h | 33 ++++++
include/uapi/drm/i915_drm.h | 13 +++
init/Kconfig | 4 +
kernel/cgroup/Makefile | 1 +
kernel/cgroup/cgroup.c | 1 +
kernel/cgroup/cgroup_driver.c | 162 ++++++++++++++++++++++++++++
17 files changed, 508 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_cgroup.c
create mode 100644 kernel/cgroup/cgroup_driver.c
--
2.14.3
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next reply other threads:[~2018-02-01 19:53 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 19:53 Matt Roper [this message]
2018-02-01 19:53 ` [PATCH RFC v2 1/7] cgroup: Allow drivers to store data associated with a cgroup Matt Roper
[not found] ` <20180201195315.4956-2-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-07 22:11 ` Tejun Heo
2018-02-01 19:53 ` [PATCH RFC v2 2/7] kernfs: Export kernfs_get_inode Matt Roper
[not found] ` <20180201195315.4956-3-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-01 20:04 ` [Intel-gfx] " Chris Wilson
2018-02-01 19:53 ` [PATCH RFC v2 3/7] cgroup: Add interface to allow drivers to lookup process cgroup membership Matt Roper
2018-02-01 20:49 ` [Intel-gfx] " Chris Wilson
2018-02-01 21:25 ` Matt Roper
2018-02-07 22:42 ` Tejun Heo
2018-02-01 19:53 ` [PATCH RFC v2 4/7] drm: Add helper to obtain cgroup of drm_file's owning process Matt Roper
[not found] ` <20180201195315.4956-5-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-01 20:10 ` [Intel-gfx] " Chris Wilson
2018-02-01 19:53 ` [PATCH RFC v2 5/7] drm/i915: cgroup integration Matt Roper
[not found] ` <20180201195315.4956-6-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-01 20:11 ` Chris Wilson
2018-02-01 20:12 ` Chris Wilson
2018-02-01 20:15 ` Chris Wilson
[not found] ` <20180201195315.4956-1-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-01 19:53 ` [PATCH RFC v2 6/7] drm/i915: Introduce 'priority offset' for GPU contexts Matt Roper
[not found] ` <20180201195315.4956-7-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-01 20:22 ` Chris Wilson
2018-02-01 19:53 ` [PATCH RFC v2 7/7] drm/i915: Add context priority & priority offset to debugfs Matt Roper
[not found] ` <20180201195315.4956-8-matthew.d.roper-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-02-01 20:24 ` Chris Wilson
2018-02-01 19:56 ` [IGT PATCH RFC] tools: Introduce intel_cgroup tool Matt Roper
2018-02-01 20:27 ` [Intel-gfx] " Chris Wilson
[not found] ` <151751685381.28099.5351495854502256843-M6iVdVfohj6unts5RBS2dVaTQe2KTcn/@public.gmane.org>
2018-02-01 23:14 ` Matt Roper
2018-02-07 21:50 ` Tejun Heo
2018-02-07 21:54 ` Tejun Heo
2018-02-01 20:14 ` ✓ Fi.CI.BAT: success for DRM management via cgroups (rev2) Patchwork
2018-02-01 20:15 ` ✗ Fi.CI.BAT: failure for tools: Introduce intel_cgroup tool Patchwork
2018-02-01 23:52 ` ✗ Fi.CI.IGT: failure for DRM management via cgroups (rev2) Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180201195315.4956-1-matthew.d.roper@intel.com \
--to=matthew.d.roper@intel.com \
--cc=cgroups@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.