summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2026-07-13 16:14:06 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2026-07-13 16:14:06 -0700
commit3b029c035b34bbc693405ddf759f0e9b920c27f1 (patch)
tree4d656f8f4ea4a2b2e8cfd73b2f981760c3985dbe /Documentation
parentf7574d3f906a963d7b70f01beff731ee0351d5c5 (diff)
parent97fef602584458b100d383afed9d176c0bc689ab (diff)
downloadlinux-3b029c035b34bbc693405ddf759f0e9b920c27f1.tar.gz
linux-3b029c035b34bbc693405ddf759f0e9b920c27f1.tar.bz2
linux-3b029c035b34bbc693405ddf759f0e9b920c27f1.zip
Merge tag 'cgroup-for-7.2-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
Pull cgroup fixes from Tejun Heo: - A cpuset that never set its memory nodes could divide by zero when a task's mempolicy rebinds on CPU hotplug. Rebind against the effective nodes, which are always populated - Documentation fixes for memory.stat, io.stat, and the misc and v1 RDMA controllers * tag 'cgroup-for-7.2-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: Docs/admin-guide/cgroup-v2: note blkcg_debug_stats gates io.latency stats Docs/admin-guide/cgroup-v1: document rdma.peak, rdma.events and rdma.events.local Docs/admin-guide/cgroup-v2: drop stale misc interface file count cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Docs/admin-guide/cgroup-v2: fix memory.stat doc details
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/admin-guide/cgroup-v1/rdma.rst66
-rw-r--r--Documentation/admin-guide/cgroup-v2.rst20
2 files changed, 78 insertions, 8 deletions
diff --git a/Documentation/admin-guide/cgroup-v1/rdma.rst b/Documentation/admin-guide/cgroup-v1/rdma.rst
index e69369b7252e..abddf34d2667 100644
--- a/Documentation/admin-guide/cgroup-v1/rdma.rst
+++ b/Documentation/admin-guide/cgroup-v1/rdma.rst
@@ -9,6 +9,7 @@ RDMA Controller
1-2. Why RDMA controller needed?
1-3. How is RDMA controller implemented?
2. Usage Examples
+ 3. RDMA Interface Files
1. Overview
===========
@@ -115,3 +116,68 @@ Following resources can be accounted by rdma controller.
(d) Delete resource limit::
echo mlx4_0 hca_handle=max hca_object=max > /sys/fs/cgroup/rdma/1/rdma.max
+
+3. RDMA Interface Files
+========================
+
+The following interface files are available in each non-root RDMA cgroup.
+
+ rdma.max
+ A read-write file which describes the configured resource limit
+ for an RDMA/IB device. See the Usage Examples above.
+
+ rdma.current
+ A read-only file which describes the current resource usage.
+
+ rdma.peak
+ A read-only nested-keyed file which shows the historical high
+ watermark of resource usage per device since the cgroup was created.
+
+ An example for mlx4 and ocrdma device follows::
+
+ mlx4_0 hca_handle=1 hca_object=20
+ ocrdma1 hca_handle=0 hca_object=23
+
+ rdma.events
+ A read-only nested-keyed file which exists on non-root cgroups
+ and contains the following keys:
+
+ max
+ The number of times a process in this cgroup or its
+ descendants attempted an RDMA resource allocation that
+ was rejected because a rdma.max limit in the subtree
+ was reached. This is a hierarchical counter propagated
+ upward to all ancestor cgroups. A value change in this
+ file generates a file modified event.
+
+ alloc_fail
+ The number of RDMA resource allocation attempts that
+ originated in this cgroup or its descendants and failed
+ due to a rdma.max limit being reached. This is a
+ hierarchical counter propagated upward.
+
+ An example for mlx4 device follows::
+
+ mlx4_0 hca_handle.max=5 hca_handle.alloc_fail=3 hca_object.max=0 hca_object.alloc_fail=0
+
+ rdma.events.local
+ Similar to rdma.events but the fields are local to the cgroup,
+ i.e. not hierarchical. The file modified event generated on this
+ file reflects only the local events.
+
+ The following nested keys are defined.
+
+ max
+ The number of times a process in this cgroup or its
+ descendants attempted an RDMA resource allocation that
+ was rejected because this cgroup's own rdma.max limit
+ was reached.
+
+ alloc_fail
+ The number of RDMA resource allocation attempts
+ originating from this cgroup that failed due to this
+ cgroup's or an ancestor's rdma.max limit.
+
+ An example for mlx4 device follows::
+
+ mlx4_0 hca_handle.max=5 hca_handle.alloc_fail=0 hca_object.max=0 hca_object.alloc_fail=0
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 993446ab66d0..14b8c571c0d1 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -1570,7 +1570,7 @@ The following nested keys are defined.
sock (npn)
Amount of memory used in network transmission buffers
- vmalloc (npn)
+ vmalloc
Amount of memory used for vmap backed memory.
shmem
@@ -1735,7 +1735,7 @@ The following nested keys are defined.
Number of pages written from zswap to swap.
zswap_incomp
- Number of incompressible pages currently stored in zswap
+ Amount of memory used by incompressible pages currently stored in zswap
without compression. These pages could not be compressed to
a size smaller than PAGE_SIZE, so they are stored as-is.
@@ -2257,10 +2257,11 @@ groups D and F will influence each other. Group G will influence nobody::
So the ideal way to configure this is to set io.latency in groups A, B, and C.
Generally you do not want to set a value lower than the latency your device
supports. Experiment to find the value that works best for your workload.
-Start at higher than the expected latency for your device and watch the
-avg_lat value in io.stat for your workload group to get an idea of the
-latency you see during normal operation. Use the avg_lat value as a basis for
-your real setting, setting at 10-15% higher than the value in io.stat.
+Start at higher than the expected latency for your device and, with
+blkcg_debug_stats enabled, watch the avg_lat value in io.stat for your
+workload group to get an idea of the latency you see during normal operation.
+Use the avg_lat value as a basis for your real setting, setting at 10-15%
+higher than the value in io.stat.
How IO Latency Throttling Works
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2298,7 +2299,9 @@ IO Latency Interface Files
io.stat
If the controller is enabled you will see extra stats in io.stat in
- addition to the normal ones.
+ addition to the normal ones. These debug stats are only emitted when
+ the blkcg_debug_stats module parameter is enabled (it is disabled by
+ default).
depth
This is the current queue depth for the group.
@@ -2934,7 +2937,8 @@ include/linux/misc_cgroup.h.
Misc Interface Files
~~~~~~~~~~~~~~~~~~~~
-Miscellaneous controller provides 3 interface files. If two misc resources (res_a and res_b) are registered then:
+Miscellaneous controller provides the following interface files. If two misc
+resources (res_a and res_b) are registered then:
misc.capacity
A read-only flat-keyed file shown only in the root cgroup. It shows