summaryrefslogtreecommitdiff
path: root/Documentation/admin-guide/clearing-warn-once.rst
diff options
context:
space:
mode:
authorDan Schatzberg <schatzberg.dan@gmail.com>2023-06-01 11:38:19 -0700
committerTejun Heo <tj@kernel.org>2023-06-05 14:08:12 -1000
commit5647e53f7856bb39dae781fe26aa65a699e2fc9f (patch)
tree22f19fd1a0b85b51e50df0f414235941af913790 /Documentation/admin-guide/clearing-warn-once.rst
parent2bd110339288c18823dcace602b63b0d8627e520 (diff)
downloadlwn-5647e53f7856bb39dae781fe26aa65a699e2fc9f.tar.gz
lwn-5647e53f7856bb39dae781fe26aa65a699e2fc9f.zip
cgroup: Documentation: Clarify usage of memory limits
The existing documentation refers to memory.high as the "main mechanism to control memory usage." This seems incorrect to me - memory.high can result in reclaim pressure which simply leads to stalls unless some external component observes and actions on it (e.g. systemd-oomd can be used for this purpose). While this is feasible, users are unaware of this interaction and are led to believe that memory.high alone is an effective mechanism for limiting memory. The documentation should recommend the use of memory.max as the effective way to enforce memory limits - it triggers reclaim and results in OOM kills by itself. Signed-off-by: Dan Schatzberg <schatzberg.dan@gmail.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Chris Down <chris@chrisdown.name> Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'Documentation/admin-guide/clearing-warn-once.rst')
0 files changed, 0 insertions, 0 deletions