There is kernel setting

/proc/sys/vm/overcommit_memory

Citation from excellent article:

Since 2.5.30 the values are: 0 (default): as before: guess about how much overcommitment is reasonable, 1: never refuse any malloc(), 2: be precise about the overcommit - never commit a virtual address space larger than swap space plus a fraction overcommit_ratio of the physical memory. Here /proc/sys/vm/overcommit_ratio (by default 50) is another user-settable parameter. It is possible to set overcommit_ratio to values larger than 100. (See also Documentation/vm/overcommit-accounting.) 

This applies to forks as well as regular malloc. I.e. if you set it to 0, fork will be copy on write. Copy on write means that once app forked, it both copies will use one page memory util copy or original starts does changes.

In most distributions I know overcommit is 0. But if you set it to 2, all memory pages will be fully backed by real memory and in some cases under high memory pressure will be more stable, but some programs (I faced gitk) which rely on overcommits will fail.

There is kernel setting

/proc/sys/vm/overcommit_memory

Citation from excellent article:

Since 2.5.30 the values are: 0 (default): as before: guess about how much overcommitment is reasonable, 1: never refuse any malloc(), 2: be precise about the overcommit - never commit a virtual address space larger than swap space plus a fraction overcommit_ratio of the physical memory. Here /proc/sys/vm/overcommit_ratio (by default 50) is another user-settable parameter. It is possible to set overcommit_ratio to values larger than 100. (See also Documentation/vm/overcommit-accounting.) 

This applies to forks as well as regular malloc. I.e. if you set it to 0, fork will be copy on write. Copy on write means that once app forked, it's both copies will share memory pages util child or original starts changing memory.

In most distributions I know overcommit is 0. But if you set it to 2, all memory pages will be fully backed by real memory and in some cases under high memory pressure will be more stable, but some programs (I faced gitk) which rely on overcommits will fail.