"heuristic overcommit" and fork()

Date: Wed Feb 11 2009 - 14:26:58 EST


Recently, I was unable to fork() a 38 GB process on a system with 64 GB RAM
and no swap.
Having a look at the kernel source, I surprisingly found that in "heuristic
overcommit" mode, fork() always checks that there is enough memory to
duplicate process memory.

As far as I know, overcommit was introduced in the kernel for several
reasons, and fork() was one of them, since applications often exec() just
after fork(). I know fork() is not the most judicious choice in this case,
but well, this is the way many applications are written.

Moreover, I can read in the proc man page that in "heuristic overcommit
mode", "obvious overcommits of address space are refused". I do not think
fork() is an obvious overcommit, that's why I would expect fork() to be
always accepted in this mode.

So, is there a reason why fork() checks for available memory in "heuristic
mode" ?

Thanks in advance.

David Champelovier

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/