I think this would be a really big improvement for workstation and other desktop spins, the handling of out of memory situations have been a consistent paint point on Linux. However, may I ask why EarlyOOM was chosen over something like NoHang [1]? I am a bit concerned that EarlyOOM's heuristics may be too coarse, as it does not take into account the newly-added PSI metrics [2][3] that other projects like NoHang, oomd, and low-memory-monitor utilize. For example, if the system is thrashing, but swap is not full, to my knowledge EarlyOOM will not see a problem, however it would be visible via PSI. To be clear, I'd rather have something in time for 32 to improve OOM handling than wait several release cycles for the ideal solution to be ready. I'm simply curious about what problems, if any, were encountered with the other potential candidates. [1] https://github.com/hakavlad/nohang [2] https://facebookmicrosites.github.io/psi/docs/overview [3] https://www.kernel.org/doc/html/latest/accounting/psi.html _______________________________________________ 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
