On Mon, Jul 13, 2020 at 11:56 AM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote: > > On Monday, July 13, 2020 10:48:03 AM MST Samuel Sieb wrote: > > On 7/13/20 8:21 AM, John M. Harris Jr wrote: > > > > > On Monday, July 13, 2020 1:58:30 AM MST Benjamin Berg wrote: > > > > > >> But, I also think that the people proposing this have done quite a lot > > >> of testing to find reasonable values for various scenarios. If they > > >> have done their job correctly, then EarlyOOM will *not* prevent you > > >> from fully utilizing your system memory in most scenarios. > > > > > > > > > By the very nature of the configuration, that's not the case. For example, > > > on my system, for example, it will start sending SIGTERM where I have > > > over 600 MiB free, and will begin to simply kill software when I have > > > over a quarter of a gigabyte left. > > > > > > You keep making this claim as if you actually know. Have you tested it? > > Have you even heard of someone else testing it that ran into that? > > Yes, I have tested it. With Swap on ZRAM, it's precisely as I described. With > no swap it's like that, and with swap of equal size, it's at 300 MiB free and > only an eight of a gigabyte left. > > That's what this software does. Its entire purpose is to kill software based > on memory criteria. It's based on both memory *and* swap criteria. Could you provide a bug report of this behavior and include a complete journal? earlyoom records the exact parameters, memory and swap free remaining at the time of either SIGTERM or SIGKILL. And in effect the defining parameter in most cases is not memory but swap, where memory free is quite substantially low. Thanks, -- 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