On Sun, Jan 5, 2020 at 12:39 AM Chris Murphy <li...@colorremedies.com> wrote: > > On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova <al...@bookwar.info> wrote: > > > Since in the Change we are not introducing just the earlyoom tool but > > enable it with a specific profile I would add those details here. Smth like: > > > > "earlyoom service will choose the offending process based on the same > > oom_score as kernel uses. It will send a SIGTERM signal on 10% of RAM left, > > and SIGKILL on 5%" > > I add this information to the summary. Also, I think these numbers may > need to change to avoid prematurely sending SIGTERM when the system > has no swap device. > > > As I understand in the current setup we are looking more for a controlled > > failure scenario rather than for a solution. > > Yes, it's fair to say this proposal is to make things "less bad". It > doesn't improve system responsiveness. Once heavy swap starts, the > system is sluggish, stutters, and briefly stalls. This proposal > doesn't fix that. There is a lot of room for improvement. > > > > Can we get a specific manual, what users supposed to do, once they trigger > > the earlyoom? Does earlyoom help in reporting? Which logs we need to look > > at? > > > > Maybe add a section in UX part of the change, or setup a dedicated wiki > > page? > > The user shouldn't need to do anything differently than if the kernel > oom-killer had triggered. The system journal will contain messages > showing what was killed and why: > > Jan 04 16:05:42 fmac.local earlyoom[4896]: low memory! at or below > SIGTERM limits: mem 10 %, swap 10 % > Jan 04 16:05:42 fmac.local earlyoom[4896]: sending SIGTERM to process > 27421 "chrome": badness 305, VmRSS 42 MiB >
I wonder, how I as a user going to be informed about the earlyoom-event? I assume abrt will recognize the crash? Will it be easily visible from the abrt report that it was the OOM? The concern is: if we enable such a service, will we get large amount of vague bug reports from users who don't understand what has happened. Can we make it somehow easier to debug? > > Additionally, there was a question during the chat discussion: how the > > earlyoom setup will work together with OOMPolicy and any other related > > options of systemd units? Will systemd recognize the OOM event? > > My understanding of systemd OOMPolicy= behavior, is it looks for the > kernel's oom-killer messages and acts upon those. Whereas earlyoom > uses the same metric (oom_score) as the oom-killer, it does not invoke > the oom-killer. Therefore systemd probably does not get the proper > hint to implement OOMPolicy= > > Fedora need to discuss how big of a problem that is, if there's anyway > to mitigate it, or tolerate it, weighing the pros of earlyoom for a > short period, versus the cons of punting this problem for another > release. This proposal does not intend to step on other superseding > work in this area, but if it does, it'll be withdrawn. > > > -- > Chris Murphy > _______________________________________________ > 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 -- Aleksandra Fedorova bookwar _______________________________________________ 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
