Ttyjfyk

I want to try cgroup v2 but am not sure if it is installed on my linux machine

>> uname -r
4.14.66-041466-generic

Since cgroup v2 is available in 4.12.0-rc5, I assume it should be available in the kernel version I am using.

https://www.infradead.org/~mchehab/kernel_docs/unsorted/cgroup-v2.html

However, it does not seem like my system has cgroup v2 as the memory interface files mentioned in its documentation are not available on my system.

https://www.kernel.org/doc/Documentation/cgroup-v2.txt

It seems like I still have cgroup v1.

/sys/fs/cgroup/memory# ls
cgroup.clone_children memory.kmem.failcnt memory.kmem.tcp.usage_in_bytes memory.memsw.usage_in_bytes memory.swappiness
cgroup.event_control memory.kmem.limit_in_bytes memory.kmem.usage_in_bytes memory.move_charge_at_immigrate memory.usage_in_bytes
cgroup.procs memory.kmem.max_usage_in_bytes memory.limit_in_bytes memory.numa_stat memory.use_hierarchy
cgroup.sane_behavior memory.kmem.slabinfo memory.max_usage_in_bytes memory.oom_control notify_on_release
docker memory.kmem.tcp.failcnt memory.memsw.failcnt memory.pressure_level release_agent
memory.failcnt memory.kmem.tcp.limit_in_bytes memory.memsw.limit_in_bytes memory.soft_limit_in_bytes tasks
memory.force_empty memory.kmem.tcp.max_usage_in_bytes memory.memsw.max_usage_in_bytes memory.stat 

Follow-up questions
Thanks Brian for the help. Please let me know if I should be creating a new question but I think it might be helpful to other if I just ask my questions here.

1) I am unable to add cgroup controllers, following the command in the doc

>> echo "+cpu +memory -io" > cgroup.subtree_control

However, I got "echo: write error: Invalid argument". Am I missing a prerequisite to this step?

2) I ran a docker container but the docker daemon log complained about not able to find "/sys/fs/cgroup/cpuset/docker/cpuset.cpus". It seems like docker is still expecting cgroupv1. What is the best way to enable cgroupv2 support on my docker daemon?

docker -v
Docker version 17.09.1-ce, build aedabb7

The easiest way is to attempt to mount the pseudo-filesystem. If you can mount it to a location, then you can attempt to manage processes with the interface:

mount -t cgroup2 none $MOUNT_POINT

I see that you cited the documentation above. One of the points you may be missing is that the paths still need to be created. There's no reason you must manage cgroup resources at any particular location. It's just convention.

For example, you could totally present procfs at /usr/monkeys... as long as the directory /usr/monkeys exists:

$ sudo mkdir /usr/monkeys
$ sudo mount -t proc none /usr/monkeys
$ ls -l /usr/monkeys
...
...
-r--r--r--. 1 root root 0 Sep 25 19:00 uptime
-r--r--r--. 1 root root 0 Sep 25 23:17 version
-r--------. 1 root root 0 Sep 25 23:17 vmallocinfo
-r--r--r--. 1 root root 0 Sep 25 18:57 vmstat
-r--r--r--. 1 root root 0 Sep 25 23:17 zoneinfo
$ sudo umount /usr/monkeys

In the same way I can do this with the cgroup v2 pseudo-filesystem:

$ sudo mount -t cgroup2 none /usr/monkeys
$ ls -l /usr/monkeys
total 0
-r--r--r--. 1 root root 0 Sep 23 16:58 cgroup.controllers
-rw-r--r--. 1 root root 0 Sep 23 16:58 cgroup.max.depth
-rw-r--r--. 1 root root 0 Sep 23 16:58 cgroup.max.descendants
-rw-r--r--. 1 root root 0 Sep 23 16:58 cgroup.procs
-r--r--r--. 1 root root 0 Sep 23 16:58 cgroup.stat
-rw-r--r--. 1 root root 0 Sep 23 16:58 cgroup.subtree_control
-rw-r--r--. 1 root root 0 Sep 23 16:58 cgroup.threads
drwxr-xr-x. 2 root root 0 Sep 23 16:58 init.scope
drwxr-xr-x. 2 root root 0 Sep 23 16:58 machine.slice
drwxr-xr-x. 59 root root 0 Sep 23 16:58 system.slice
drwxr-xr-x. 4 root root 0 Sep 23 16:58 user.slice
$ sudo umount /usr/monkeys

You could run the following command:

cat /proc/filesystems | grep cgroup

If your system supports cgroupv2, you would see:

nodev cgroup
nodev cgroup2

On a system with only cgroupv1, you would only see:

nodev cgroup