[OpenWrt-Devel] overcommit memory/ratio
David Lang
david at lang.hm
Sat Sep 20 05:00:41 EDT 2014
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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list