On Friday, July 3, 2020 10:11:53 PM MST Alexey Avramov wrote: > >it should be disabled so it doesn't kill our software > > > What should people who suffer from the fact that the kernel's OOM killer > does not work, and they are forced to hard reboot (and lose unsaved data) > the computer when it freezes? This is a serious and very common problem > that exists for a long time and has not been fixed out of the box. I've never managed to get one of my own Fedora machines to the point of OOMing, and, when I have seen others do it, it's a problem that would have been solved by having more swap space. > What do you suggest? Should we do nothing? That's precisely what I suggest. > > Of course, we can do nothing and wait for the inclusion of the system-oomd > in the systemd [7]. Just wait. How is that disabled? > Also look at these discussions: > - Why are low memory conditions handled so badly? [1] They're not. The system lets you do precisely what you're trying to do. > - Memory management "more effective" on Windows than Linux? (in preventing > total system lockup) [2] Windows memory management used to mean that you couldn't map more than something like 2 GiB per program. Has that been fixed, or is it still completely broken? I'd certainly not call artificial limitations like that "more effective". > - Let's talk about the elephant in the room - the > Linux kernel's inability to gracefully handle low memory pressure [3] [4] Linux handles low memory situations just fine, but it's much better if you have an appropriately sized swap partition and let the kernel do its job (don't turn down swappiness) > [5] - How do I prevent Linux from freezing when out of memory? Today I > (accidentally) ran some program on my Linux box that quickly used a lot of > memory. My system froze, became unresponsive and thus I was unable to kill > the offender. How can I prevent this in the future? Can't it at least keep > a responsive core or something running? [6] If you didn't mean for the program to use as much memory as it tried to, the correct solution would be to use cgroups. -- 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
