mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage

[cascardo/linux.git] / Documentation / cgroup-v2.txt

diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index ff49cf9..8f1329a 100644 (file)
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -843,6 +843,15 @@ PAGE_SIZE multiple when read back.
                Amount of memory used to cache filesystem data,
                including tmpfs and shared memory.
 
+         kernel_stack
+
+               Amount of memory allocated to kernel stacks.
+
+         slab
+
+               Amount of memory used for storing in-kernel data
+               structures.
+
          sock
 
                Amount of memory used in network transmission buffers
@@ -871,6 +880,16 @@ PAGE_SIZE multiple when read back.
                on the internal memory management lists used by the
                page reclaim algorithm
 
+         slab_reclaimable
+
+               Part of "slab" that might be reclaimed, such as
+               dentries and inodes.
+
+         slab_unreclaimable
+
+               Part of "slab" that cannot be reclaimed on memory
+               pressure.
+
          pgfault
 
                Total number of page faults incurred
@@ -1368,6 +1387,12 @@ system than killing the group.  Otherwise, memory.max is there to
 limit this type of spillover and ultimately contain buggy or even
 malicious applications.
 
+Setting the original memory.limit_in_bytes below the current usage was
+subject to a race condition, where concurrent charges could cause the
+limit setting to fail. memory.max on the other hand will first set the
+limit to prevent new charges, and then reclaim and OOM kill until the
+new limit is met - or the task writing to memory.max is killed.
+
 The combined memory+swap accounting and limiting is replaced by real
 control over swap space.