Hi, This is a follow-up for this thread: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/ Has anyone looked at oomd, or is anyone interested in testing and comparing it to alternatives? https://facebookmicrosites.github.io/oomd/docs/overview https://news.ycombinator.com/item?id=17590858 The origin for oomd is servers, and the case study at Facebook is also server centric. But oomd is also very flexible, with the option to arrive over the medium term a cooperative approach to resource management. However, my more immediate interest is to make heavy memory pressure and swap usage (versus incidental use of swap) result in a more predictable outcome. Right now this is all over the map, maybe the process you would have picked to kill (if you could) is killed. Maybe something else is killed and you don't notice, but it frees up just enough memory to prevent anything else from being killed, and now you're stuck in swap hell. It's a lot of maybes. And the final implosion of a system isn't really what matters because at this point, once it happens, the system is already in some kind of tail spin. And what that means is we can't even really iterate on any improvements because all the outcomes right now appear to suck. So how about avoiding tail spins in the first place? And a quick search, Lennart mentions oomd in the 'raise fileno limit...' thread from Oct 2018 during early discussions of cgroupsv2. -- 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
