On Wed, 17 Sep 2014, Nikos Mavrogiannopoulos wrote:
On Tue, 2014-09-16 at 22:29 +0000, Karl P wrote:
Alternatively, if you know which process it is, set it's oom_adj_score so that
it gets killed first.
Some other people are kinda used to things behaving as
they are, for better or worse. (Turning off overcommit on an openwrt device is
no different than turning off overcommit on a desktop as far as I'm concerned.
Somethings will be better, lots of things less so)
Well being used to something bad, doesn't mean things cannot get better.
Routers (to which I have some experience at), rarely have processes
running that wouldn't matter if they are randomly killed; on a desktop
system you immediately notice an issue, and you can reboot, a router is
typically running unattended. Being locked out of such a system because
another process had a memory leak, can be an issue.
Turning off overcommit so that a program that wants to spawn a child will end up
requiring double it's memory (for the time between the fork and the exec) is
likely to cause programs to fail when they don't need to.
And unlike desktops, you can't just say "allocate a lot of swap" to cover this
up.
In spite of what some people say, it's far from a clear-cut win to disable
overcommit.
David Lang
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
