Hello, On Thu, Jun 01, 2023 at 11:38:19AM -0700, Dan Schatzberg wrote: > 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@xxxxxxxxx> Applied to cgroup/for-6.4-fixes. Please see below for a comment tho. > @@ -1213,23 +1213,25 @@ PAGE_SIZE multiple when read back. > A read-write single value file which exists on non-root > cgroups. The default is "max". > > - Memory usage throttle limit. This is the main mechanism to > - control memory usage of a cgroup. If a cgroup's usage goes > + Memory usage throttle limit. If a cgroup's usage goes > over the high boundary, the processes of the cgroup are > throttled and put under heavy reclaim pressure. > > Going over the high limit never invokes the OOM killer and > - under extreme conditions the limit may be breached. > + under extreme conditions the limit may be breached. The high > + limit should be used in scenarios where an external process > + monitors the limited cgroup to alleviate heavy reclaim > + pressure. I think it'd be helpful to provide pointers to oomd and systemd's implementation of it here. Thanks. -- tejun
