On Sun, Jan 5, 2020 at 12:39 AM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> 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@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 -- Aleksandra Fedorova bookwar _______________________________________________ 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
