>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.
>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 <johnmh@xxxxxxxxxxxxx>:
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@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
_______________________________________________ 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
