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@xxxxxxxxx> 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-interface-files Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
