Hello, Matt. On Tue, Jan 02, 2018 at 04:12:02PM -0800, Matt Roper wrote: > To make sure I'm understanding correctly --- you're suggesting that > instead of using a cgroup controller to add values (priority, vram, > etc.) as directly-accessible file nodes under a cgroup's kernfs > directory that I instead add new driver-specific ioctls (e.g., > DRM_IOCTL_SET_CGROUP_PRIORITY) to programmatically update a driver > internal cgroup=>priority mapping table? I think that roughly matches > what I see the bpf code doing with BPF_PROG_ATTACH in the bpf syscall. Yes, something along that line. > I was originally hoping for some way that a driver could add entries to > the cgroup directory since that's easy to configure with something as > simple as a sysv-init script (and matches how other system policy values > will be updated). But I guess we can write a simple userland tool to go > with our driver that can be called from such a script. > > I guess the other alternative would be to try to mirror the cgroup > hierarchy in a driver-specific sysfs or debugfs tree where we'd add our > own value files, but that's probably more hassle than it's worth. It really depends on whether it needs to be full-fledged resource controller or not. The reason bpf is that way is because it can't be delegated and thus fits better when treated as a bpf mechanism which also matches cgroup membership rather than the other way around. On the other hand, rdma is a full controller because it does fit the resource controller model. I have no idea what your requirements are, so I can't tell what'd fit your use case better. It'd be great if you can ELI5 what you have on mind. 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
