[Intel-gfx] [PATCH v4 0/8] cgroup private data and DRM/i915 integration

[Joonas Lahtinen]

Quoting Matt Roper (2018-03-23 17:46:16)
> On Fri, Mar 23, 2018 at 02:15:38PM +0200, Joonas Lahtinen wrote:
> > Quoting Matt Roper (2018-03-17 02:08:57)
> > > This is the fourth 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
> > >   (v3) https://lists.freedesktop.org/archives/intel-gfx/2018-March/157928.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.
> > 
> > Hi Matt,
> > 
> > For cross-subsystem changes such as this, it makes sense to Cc all
> > relevant maintainers, especially if there have been previous comments to
> > earlier revisions.
> > 
> > Please, do include and keep a reference to the userspace portion of the
> > changes when you suggest new uAPI to be added. At least I have some trouble
> > trying to track down the relevant interface consumer here.
> > 
> > I'm unsure how much sense it makes to commence with detailed i915 review
> > if we will be blocked by lack of userspace after that? I'm assuming
> > you've read through [1] already.
> 
> Hi Joonas,
> 
> I've sent the userspace code out a few times, but it looks like I forgot
> to include a copy with v4/v4.5.  Here's the version I provided with v3:
>   https://lists.freedesktop.org/archives/intel-gfx/2018-March/157935.html

Thanks. Keeping that in the relevant commit message of the patch that
introduces the new uAPI will make it harder to forget and easiest for
git blame, too.

> 
> Usually we don't consider things like i-g-t to be sufficient userspace
> consumers because we need a real-world consumer rather than a "toy"
> userspace.  However in this case, the i-g-t tool, although very simple,
> is really the only userspace consumer I expect there to ever be.
> Ultimately the true consumer of this cgroups work are bash scripts, sysv
> init scripts, systemd recipes, etc.  that just need a very simple tool
> to assign the specific values that make sense on a given system.
> There's no expectation that graphics clients or display servers would
> ever need to make use of these interfaces.

I was under the impression that a bit more generic GPU cgroups support
was receiving a lot of support in the early discussion? A dedicated
intel_cgroup sounds underwhelming, when comparing to idea of "gpu_nice",
for user adoption :)

Also, I might not be up-to-date about all things cgroups, but the way
intel_cgroup works, feels bit forced. We create a userspace context just
to communicate with the driver and the IOCTL will still have global
effects. I can't but think that i915 reading from the cgroups subsystem
for the current process would feel more intuitive to me.

Does the implementation mimic some existing cgroups tool or de-facto way
of doing things in cgroups world?

Regards, Joonas