On Saturday, July 18, 2020 3:25:35 AM MST Benjamin Berg wrote: > On Fri, 2020-07-17 at 19:44 -0700, John M. Harris Jr wrote: > > On Friday, July 17, 2020 10:06:53 AM MST Benjamin Berg wrote: > > > What we achieve by killing a process is that we give the kernel more > > > flexibility in how it manages the available memory. It really doesn't > > > matter what you kill, all that matters is that some memory is free'ed > > > up again. > > > > It does matter what you kill, because you're wiping out users' data and > > stopping software the user intended to have run. The kernel is already > > more > > than capable of freeing memory for itself, that's not what this Change is > > for either. This Change is to abuse the OOM killer to run in non-OOM > > scenarios using a userspace daemon. > > No, an OOM scenario from a kernel point of view means, that it has no > other choice than to kill a process. Users' processes should NEVER be killed, unless there is no other choice to keep the system running. > You *really* need to accept that the kernel OOM killer is insufficient > in many scenarios. It is only the last line of defence, that is solely > concerned about whether the system is *technically* capable of running. It's more than sufficient for the goal you listed, which is to keep the kernel working. > But thrashing scenarios are exactly that, *technically* running but > *practically* dead. Thrashing doesn't mean the system is unusable, or anything of the sort. It's only an issue if you're thrashing for too long. > I think it only makes sense to continue a discussion if you acknowledge > the existence and really understand the scenario described here: > https://lkml.org/lkml/2019/8/4/15 I've linked to that very thread several times in this thread. The bug here is in the web browsers that cause that behavior. The solution is to either fix the web browsers or limit the amount of memory they can run away with. -- 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
