From 9a95dcb6a69a1cfb4e7dae20ef0e2050b8413950 Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Mon, 16 Jan 2017 16:09:24 +1300 Subject: [PATCH] vfork.2: Another reason to use vfork() is to avoid overcommitting memory Signed-off-by: Michael Kerrisk --- man2/vfork.2 | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/man2/vfork.2 b/man2/vfork.2 index a57ea7a42..bfc689b6e 100644 --- a/man2/vfork.2 +++ b/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 .\" .\" %%%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