The Natural Philosopher  writes:
> Dennis Lee Bieber  wrote:
>>   I ran a benchmark about two+ years ago which required significant swap
>> space to complete; otherwise the Out-of-Memory monitor would kill it
>> (somewhat strange, since the program was designed to take a failure from
>> malloc() as signal to shut down and report results -- and that part worked
>> on a No-OS embedded system).
>
> Why would malloc() fail if there was swap space?

ulimit can cause that.

But the question was why malloc succeeded but the process was later
zapped by the OOM killer. The answer is Linux doesn’t back newly
allocated memory mappings with anything until they are actually used;
thus it’s possible to allocate much more memory than you have (in the
form of RAM and swap) and only run into trouble when you try to use it.

The reason is that it’s fairly routine for Unix process to request much
more memory than they actually need, so without this strategy you’d have
to allocate an awful lot of swap that you never actually used. The most
obvious example is that process that forks and then execs, i.e. anything
that ever runs a subcommand.

AFAIK you can turn this behavior (“overcommit”) off if you want.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05