[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
From: "Alexey A." <hakavlad () gmail ! com>
Date: 2020-07-19 8:47:23
Message-ID: CADrZ5ZXhhT9DPpNOU-Ah3X-K5cYq+18PaPK3vSwiM5csxHUfxw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
>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.
=D0=B2=D1=81, 19 =D0=B8=D1=8E=D0=BB. 2020 =D0=B3. =D0=B2 12:42, John M. Har=
ris Jr <johnmh@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, an=
d
> 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 ou=
r
> 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-leave@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.o=
rg
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>>Killing users' programs needlessly is not \
welcome</div><div><br></div><div>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.</div><div><br></div><div>>The goal is to ensure the kernel can keep doing \
its job, it's<br>>not going to try to figure out what you intend for \
userspace, as well it<br>>shouldn't.<br><br>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.</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">вс, 19 июл. 2020 г. в \
12:42, John M. Harris Jr <<a \
href="mailto:johnmh@splentity.com">johnmh@splentity.com</a>>:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">On Saturday, July 18, 2020 6:33:11 PM MST Brandon \
Nielsen wrote:<br> > What about the case of the developer whose code accidentally \
does <br> > something that blows through all available memory, leading to swap \
<br> > thrashing. I've been there. The system is very much unusable, to the \
<br> > point where a user without the knowledge of the magic sysrq key will <br>
> almost certainly be reaching for the power button.<br>
<br>
Well, sysrq is disabled by default in Fedora anyway. I get what you mean, <br>
however, as I also re-enable it.<br>
<br>
> Or when a compile takes more memory than you expect, leading to the <br>
> same? Again, I've been there. The system is absolutely unusable for any <br>
> regular user use-case I can think of.<br>
<br>
This is another example that came up, and cgroups can help with that as well. <br>
<br>
> Decompression "bomb" (malicious or otherwise) on a memory taxed \
system? <br> > Again, definitely unusable.<br>
> <br>
> Web browsers are definitely not the only way thrashing can be <br>
> encountered. While I agree resource limits via cgroups or other method <br>
> are needed, an EarlyOOM emergency brake is definitely welcome as well. <br>
> The kernel OOM killer is certainly not adequate for an interactive user <br>
> session in my experience.<br>
<br>
Killing users' programs needlessly is not welcome, at least not by me, and \
I'd <br> certainly hope others wouldn't stand for it either. The correct \
solution is to <br> prevent the few programs that this is an issue with from eating \
all of our <br> RAM, not killing everything but those. The kernel OOM killer does its \
job, and <br> it does it well. The goal is to ensure the kernel can keep doing its \
job, it's <br> not going to try to figure out what you intend for userspace, as \
well it <br> shouldn't.<br>
<br>
-- <br>
John M. Harris, Jr.<br>
<br>
_______________________________________________<br>
devel mailing list -- <a href="mailto:devel@lists.fedoraproject.org" \
target="_blank">devel@lists.fedoraproject.org</a><br> To unsubscribe send an email to \
<a href="mailto:devel-leave@lists.fedoraproject.org" \
target="_blank">devel-leave@lists.fedoraproject.org</a><br> Fedora Code of Conduct: \
<a href="https://docs.fedoraproject.org/en-US/project/code-of-conduct/" \
rel="noreferrer" target="_blank">https://docs.fedoraproject.org/en-US/project/code-of-conduct/</a><br>
List Guidelines: <a href="https://fedoraproject.org/wiki/Mailing_list_guidelines" \
rel="noreferrer" target="_blank">https://fedoraproject.org/wiki/Mailing_list_guidelines</a><br>
List Archives: <a href="https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org" \
rel="noreferrer" target="_blank">https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org</a><br>
</blockquote></div>
[Attachment #6 (text/plain)]
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic