Check out my first novel, midnight's simulacra!
Cpuset: Difference between revisions
(Created page with '* [http://www.bullopensource.org/cpuset/ CPUSETS for Linux 2.6] at http://bullopensource.org/cpuset/ * [http://oss.sgi.com/projects/cpusets/ libcpuset] at http://oss.sgi.com/proj...') |
No edit summary |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
CPUsets are '''deprecated''' on Linux, and have been for some time! They are implemented in terms of version 1 control groups. Almost everything one can do with a a CPUset can be done with a [[Control Groups|version 2 control group]] plus the <tt>cpuset</tt> controller, but it will be better integrated with other resource controllers, and be [https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#issues-with-v1-and-rationales-for-v2 more reliable]. | |||
Don't use CPUsets! This includes libcpuset, which is a farce, and the cgroupv1 filesystem often mounted at <tt>/dev/cpuset</tt>. | |||
You will not be able to mount the cpuset hierarchy if the unified cgroupv2 hierarchy exists, and <tt>cpuset</tt> is present in any <tt>cgroup.subtree_control</tt> node (the mount will fail with <tt>EBUSY</tt>). Likewise, a mounted cpuset hierarchy will prevent <tt>cpuset</tt> from being added to a cgroupv2 <tt>cgroup.subtree_control</tt> (the write will fail with <tt>ENOENT</tt>). | |||
* [http://www.bullopensource.org/cpuset/ CPUSETS for Linux 2.6] at http://bullopensource.org/cpuset/ | * [http://www.bullopensource.org/cpuset/ CPUSETS for Linux 2.6] at http://bullopensource.org/cpuset/ | ||
* [http://oss.sgi.com/projects/cpusets/ libcpuset] at http://oss.sgi.com/projects/cpusets/ | * [http://oss.sgi.com/projects/cpusets/ libcpuset] at http://oss.sgi.com/projects/cpusets/ | ||
Latest revision as of 20:00, 14 January 2023
CPUsets are deprecated on Linux, and have been for some time! They are implemented in terms of version 1 control groups. Almost everything one can do with a a CPUset can be done with a version 2 control group plus the cpuset controller, but it will be better integrated with other resource controllers, and be more reliable.
Don't use CPUsets! This includes libcpuset, which is a farce, and the cgroupv1 filesystem often mounted at /dev/cpuset.
You will not be able to mount the cpuset hierarchy if the unified cgroupv2 hierarchy exists, and cpuset is present in any cgroup.subtree_control node (the mount will fail with EBUSY). Likewise, a mounted cpuset hierarchy will prevent cpuset from being added to a cgroupv2 cgroup.subtree_control (the write will fail with ENOENT).
