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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to