vfork.2: Another reason to use vfork() is to avoid overcommitting memory

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

man2/vfork.2

@@ -1,4 +1,5 @@
 .\" Copyright (c) 1999 Andries Brouwer (aeb@cwi.nl), 1 Nov 1999
+.\" and Copyright 2006, 2012, 2017 Michael Kerrisk <mtk.manpages@gmail.com>
 .\"
 .\" %%%LICENSE_START(VERBATIM)
 .\" Permission is granted to make and distribute verbatim copies of this
@@ -210,6 +211,23 @@ is designed to be implementable on systems that lack an MMU.)
 .\" http://developers.sun.com/solaris/articles/subprocess/subprocess.html
 .\" http://mailman.uclinux.org/pipermail/uclinux-dev/2009-April/000684.html
 .\"
+.IP *
+On systems where memory is constrained,
+.BR vfork ()
+avoids the need to temporarily commit memory (see the description of
+.IR /proc/sys/vm/overcommit_memory
+in
+.BR proc (5))
+in order to execute a new program.
+(This can be especifially beneficial where a large parent process wishes
+to execute a small helper program in a child process.)
+By contrast, using
+.BR fork (2)
+in this scenario requires either committing an amount of memory equal
+to the size of the parent process (if strict overcommitting is in force)
+or overcommiting memory with the risk that a process is terminated
+by the out-of-memory (OOM) killer.
+.\"
 .SS Caveats
 The child process should take care not to modify the memory in unintended ways,
 since such changes will be seen by the parent process once