> I have a program that keeps malloc()ing (and scribbling a bit into > the allocated memory) until malloc() fails. The intention is to put > pressure on the VM system to find out how much pool cache memory it > can reclaim.
> When I run that program (with swap space unconfigured), it doesn't > terminate normally, but gets killed by the kernel with "out of swap". > Unfortunately, other processes happening to malloc() during that time > may get killed, too. As I think someone else said, it doesn't die in malloc, but in a page fault incurred when accessing the new memory. Other processes that get killed also get killed in page faults, not in malloc()s. > I don't quite get what the rationale for that is (or maybe I'm doing > something stupidely wrong). If I malloc(), and that fails, that > should fail and not kill me, no? One would think. But the system overcommits VM, allowing the total VM to exceed the available RAM (well, RAM+swap, but you said you had no swap configured). This is semi-necessary, to support things like a large process doing fork+exec (where almost all the VM is COW-shared between the fork and the exec, but doubling the VM use of the process would exceed available RAM). But it does mean that trying to allocate a new page, usually during a write pagefault to a COW or demand-zero page, can leave the OS with no available pages. Since there is no way to return an error to the "offending" process, the only alternatives are to kill the process, kill some _other_ process, or put the faulting process to sleep indefinitely in the hope that someone else will free up some memory. Someone chose the first of those options. (It is arguably the best of a rather bad lot.) I don't know whether there is a way to turn off VM overcommit. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
