On Tue, Jan 07, 2020 at 09:19:47AM -0600, Michael Catanzaro wrote:
On Tue, Jan 7, 2020 at 5:27 am, Mark Otaris <mark(a)net-c.com>
wrote:
>Try it. With a memory limit,
>
>podman run --rm -it --memory=1G fedora bash -c 'dnf install -y
>stress-ng && stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm
>100'
>
>will use CPU but keep your system responsive. Without the memory limit
>(this will hang your system),
>
>podman run --rm -it fedora bash -c 'dnf install -y stress-ng &&
>stress-ng --malloc 100 --memcpy 100 --mmap 100 --vm 100'
>
>the system hangs and doesn’t recover after 15 minutes.
I don't think we can use this, though; or at least, I don't see how.
systemd allows limiting the memory accessible to a scope, but it
doesn't allow carving out memory for one particular scope that is
not to be accessible to other scopes. So I don't see a way to use
these memory limits to ensure sufficient memory remains available to
critical session processes. (Am I missing something?)
systemd is just a proxy for the kernel here.
The kernel allows memory.min to be set, which is defined as [1]
Hard memory protection. If the memory usage of a cgroup is within
its effective min boundary, the cgroup’s memory won’t be reclaimed
under any conditions.
There is also memory.low which is weaker:
Best-effort memory protection. If the memory usage of a cgroup is
within its effective low boundary, the cgroup’s memory won’t be
reclaimed unless there is no reclaimable memory available in
unprotected cgroups.
I think that a combination of those two settings could be sufficient
to give us appropriate memory protection for a graphical session.
I envision the limits as being set using some simple formula based
on the total RAM available and the desktop environment used at machine
boot.
[1]
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-...
Zbyszek