Re: [PATCH 1/2] Documentation/cgroup-v1: fix outdated programming details

[Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

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