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