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

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

[Matt Roper]

The cgroup-v1 documentation is out of date in a few places:

 * cgroup controllers can no longer be compiled as modules since commit
   3ed80a6 ("cgroup: drop module support"); the functions and fields
   referenced here no longer exist.

 * Controllers need to create of a cgroup_subsys object named
   "<name>_cgrp_subsys" instead of "<name>_subsys" since commit
   073219e ("cgroup: clean up cgroup_subsys names and initialization")

Cc: Tejun Heo <tj@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
 Documentation/cgroup-v1/cgroups.txt | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/Documentation/cgroup-v1/cgroups.txt b/Documentation/cgroup-v1/cgroups.txt
index 308e5ff..059f706 100644
--- a/Documentation/cgroup-v1/cgroups.txt
+++ b/Documentation/cgroup-v1/cgroups.txt
@@ -523,12 +523,7 @@ Accessing a task's cgroup pointer may be done in the following ways:
 Each subsystem should:
 
 - add an entry in linux/cgroup_subsys.h
-- define a cgroup_subsys object called <name>_subsys
-
-If a subsystem can be compiled as a module, it should also have in its
-module initcall a call to cgroup_load_subsys(), and in its exitcall a
-call to cgroup_unload_subsys(). It should also set its_subsys.module =
-THIS_MODULE in its .c file.
+- define a cgroup_subsys object called <name>_cgrp_subsys
 
 Each subsystem may export the following methods. The only mandatory
 methods are css_alloc/free. Any others that are null are presumed to
-- 
2.9.5

[PATCH 2/2] cgroup: Update documentation reference

[Matt Roper]

The cgroup_subsys structure references a documentation file that has been
renamed after the v1/v2 split.  Since the v2 documentation doesn't
currently contain any information on kernel interfaces for controllers,
point the user to the v1 docs.

Cc: Tejun Heo <tj@kernel.org>
Cc: linux-doc@vger.kernel.org
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
---
 include/linux/cgroup-defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 8b7fd8e..9f242b8 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -561,7 +561,7 @@ struct cftype {
 
 /*
  * Control Group subsystem type.
- * See Documentation/cgroups/cgroups.txt for details
+ * See Documentation/cgroup-v1/cgroups.txt for details
  */
 struct cgroup_subsys {
 	struct cgroup_subsys_state *(*css_alloc)(struct cgroup_subsys_state *parent_css);
-- 
2.9.5

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

[Matt Roper]

On Fri, Dec 29, 2017 at 12:01:59PM -0800, Matt Roper wrote:
> The cgroup-v1 documentation is out of date in a few places:
> 
>  * cgroup controllers can no longer be compiled as modules since commit
>    3ed80a6 ("cgroup: drop module support"); the functions and fields
>    referenced here no longer exist.
...

This is actually exactly what I was digging into the cgroups
documentation to figure out how to do.  I was hoping to be able to
create a controller inside an existing device driver that could manage
driver-specific policy and resources.  However based on the explanation
given in https://www.spinics.net/lists/cgroups/msg10077.html , it sounds
like this isn't really a direction that the cgroups framework wants to
go.

My specific goal was to use the cgroups-v2 hierarchy to assign i915
(GPU) workloads with an initial priority according to the cgroup
classification of the submitting process.  In the future I could also
see driver-specific cgroup controllers potentially being useful for
managing specialized resources like graphics-specific stolen memory or
video RAM on discrete gpu's.

If a system is already using a cgroups-v2 hierarchy to manage other
system resources via the standard controllers, I think it would be ideal
if we could leverage that existing process organization to supply i915
with desired driver-specific policy and resource assignments.  Since
cgroup controllers don't seem to support this at the moment, is there an
alternate mechanism I should be looking at instead?  Or is this a type
of use case that we may want to evolve cgroups to support in a different
manner?

Thanks!


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

Re: [PATCH 2/2] cgroup: Update documentation reference

[Tejun Heo]

On Fri, Dec 29, 2017 at 12:02:00PM -0800, Matt Roper wrote:
> The cgroup_subsys structure references a documentation file that has been
> renamed after the v1/v2 split.  Since the v2 documentation doesn't
> currently contain any information on kernel interfaces for controllers,
> point the user to the v1 docs.
> 
> Cc: Tejun Heo <tj@kernel.org>
> Cc: linux-doc@vger.kernel.org
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>

Applied 1-2 to cgroup/for-4.16.

Thanks.

-- 
tejun

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

[Tejun Heo]

Hello, Matt.

On Fri, Dec 29, 2017 at 12:34:49PM -0800, Matt Roper wrote:
> If a system is already using a cgroups-v2 hierarchy to manage other
> system resources via the standard controllers, I think it would be ideal
> if we could leverage that existing process organization to supply i915
> with desired driver-specific policy and resource assignments.  Since
> cgroup controllers don't seem to support this at the moment, is there an
> alternate mechanism I should be looking at instead?  Or is this a type
> of use case that we may want to evolve cgroups to support in a different
> manner?

cgroup membership of a task and the hierarchical relationships of
cgroups can be determined trivially.  Unless the resource in question
needs to and can strictly follow the resource rules for cgroup
controllers, which can become really involving and invasive, the
better and easier approach is using cgroup membership as an extra
information from the subsystem, which is how the network and bpf
handle cgroup membership too.

Thanks.

-- 
tejun

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

[Matt Roper]

On Tue, Jan 02, 2018 at 07:05:02AM -0800, Tejun Heo wrote:
> Hello, Matt.
> 
> On Fri, Dec 29, 2017 at 12:34:49PM -0800, Matt Roper wrote:
> > If a system is already using a cgroups-v2 hierarchy to manage other
> > system resources via the standard controllers, I think it would be ideal
> > if we could leverage that existing process organization to supply i915
> > with desired driver-specific policy and resource assignments.  Since
> > cgroup controllers don't seem to support this at the moment, is there an
> > alternate mechanism I should be looking at instead?  Or is this a type
> > of use case that we may want to evolve cgroups to support in a different
> > manner?
> 
> cgroup membership of a task and the hierarchical relationships of
> cgroups can be determined trivially.  Unless the resource in question
> needs to and can strictly follow the resource rules for cgroup
> controllers, which can become really involving and invasive, the
> better and easier approach is using cgroup membership as an extra
> information from the subsystem, which is how the network and bpf
> handle cgroup membership too.

Hi Tejun.

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.

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.

Thanks for your help.


Matt

> 
> Thanks.
> 
> -- 
> tejun
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

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

[Tejun Heo]

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