>Killing users' programs needlessly is not welcome Setting limits for cgroup (MemoryMax, MemorySwapMax) leads to "Killing users' programs needlessly": system-wide available memory may be not exhausted, but OOM killer will be invoked in this cgroup.
>The goal is to ensure the kernel can keep doing its job, it's >not going to try to figure out what you intend for userspace, as well it >shouldn't. The goal is to ensure the kernel can keep doing its job *and userspace* doing its job. I don't need a system where the kernel is alive, but userspace is dead. вс, 19 июл. 2020 г. в 12:42, John M. Harris Jr <joh...@splentity.com>: > On Saturday, July 18, 2020 6:33:11 PM MST Brandon Nielsen wrote: > > What about the case of the developer whose code accidentally does > > something that blows through all available memory, leading to swap > > thrashing. I've been there. The system is very much unusable, to the > > point where a user without the knowledge of the magic sysrq key will > > almost certainly be reaching for the power button. > > Well, sysrq is disabled by default in Fedora anyway. I get what you mean, > however, as I also re-enable it. > > > Or when a compile takes more memory than you expect, leading to the > > same? Again, I've been there. The system is absolutely unusable for any > > regular user use-case I can think of. > > This is another example that came up, and cgroups can help with that as > well. > > > Decompression "bomb" (malicious or otherwise) on a memory taxed system? > > Again, definitely unusable. > > > > Web browsers are definitely not the only way thrashing can be > > encountered. While I agree resource limits via cgroups or other method > > are needed, an EarlyOOM emergency brake is definitely welcome as well. > > The kernel OOM killer is certainly not adequate for an interactive user > > session in my experience. > > Killing users' programs needlessly is not welcome, at least not by me, and > I'd > certainly hope others wouldn't stand for it either. The correct solution > is to > prevent the few programs that this is an issue with from eating all of our > RAM, not killing everything but those. The kernel OOM killer does its job, > and > it does it well. The goal is to ensure the kernel can keep doing its job, > it's > not going to try to figure out what you intend for userspace, as well it > shouldn't. > > -- > John M. Harris, Jr. > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
