On Sat, 20 Sep 2014, Nikos Mavrogiannopoulos wrote:
On Fri, 2014-09-19 at 18:39 -0700, David Lang wrote
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.
I'd be surprised if fork and exec worked that way. After a fork the two
processes share the same physical pages (see the notes on fork()
manpage), and overcommit applies to physical ram, not virtual.
No, Overcommit says that you can have more virtual RAM than physical RAM + swap.
That's what overcommit is.
So when you fork a process, it takes double the memory with overcommit off than
it does with overcommit on.
And unlike desktops, you can't just say "allocate a lot of swap" to
cover this up.
The same argument works the other way as well. A process using more
memory than the available in the router will force some other
(arbitrary) process to be killed. Unlike desktops you can't just say
"allocate a lot of swap" to cover this up.
What you _can_ do, is tell to the process that uses more memory than the
existing one, that there is no memory left.
But turning overcommit off doesn't tell a process that uses more memory than the
existing one that there is no memory left, it tells the first process that tries
to allocate memory after it runs out that there is no memory left.
This could be the process that's using an unusual amount of memory, or it could
be sshd allocating a buffer to use to log.
Even if it gets the right process, you are assuming that the programs properly
check for errors after anything that allocates memory. This is very commonly not
the case, so you still get random failures.
David Lang
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
