Hello, Matt, Chris. On Thu, Feb 01, 2018 at 03:14:38PM -0800, Matt Roper wrote: > > Hmm. Could we not avoid drm_ioctl + well known param names and use a > > more generic tool to set cgroup attributes? Just feels wrong that a > > such a generic interface boils down to a driver specific ioctl. So, everything which shows up in the cgroup hierarchy should satisfy the following two conditions. * The control mechanism should adhere to one of the resource distribution models defined in Documentation/cgroup-v2.txt. This is to ensure consistency across different resources which in turn allows things like delegation. * This one is a bit vague and I probably should find a better way to describe it but each controller should encapsulate a generic core resource. Here, I don't think it makes sense to have intel gfx controller when there are a lot of commmonalities in the graphics hardware across different vendors. It should be better abstracted. It's true that it's difficult to figure out the right generic design without actually trying, and I think that's why it'd be better to start scoped in the scope of the specific driver. The smaller scope would allow for less strict expectations, more latitude, and easier experimentations. > I think the nicest interface for setting cgroup attributes would be to > find a way to add our own kernfs entries to the cgroup filesystem, the > same way real cgroup controllers do. Then we could do something like > "echo 123 > /cgroup2/apps/highprio/i915.card0.priority" and not need to > call any ioctl's at all. Without creating an actual cgroup controller, > I think this might be challenging, but I'm investigating it on the side > right now to see if it's a viable option. So, I strongly believe that it isn't the right approach to add i915 prefixed interface files to cgroup interface. Thanks. -- tejun -- 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
