Hi,
This is a follow-up for this thread:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/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@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