[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