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. > 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. > In spite of what some people say, it's far from a clear-cut win to > disable overcommit. I don't think anyone claims that. regards, Nikos _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel