Review request for 5049299
martinrb at google.com
Sat Jun 27 17:21:58 UTC 2009
Although clone(CLONE_VFORK...) didn't work out,
using glibc's vfork instead did. The glibc code to handle vfork
is quite different from the code for clone(CLONE_VM | CLONE_VFORK),
especially for saving/restoring pids.
This time, I tested on 32-bit and 64-bit Linux.
Michael, please review.
As always, we'll need a bug filed.
Synopsis: (process) Use vfork, not fork, on Linux to avoid swap exhaustion
And again, my changes are conflicting with Michael's changes for Solaris.
I will negotiate with Michael for who gets to commit first.
We will likely end up with 4 different strategies for "forking":
fork, clone, vfork, and helper process.
Note to integrators: the process changes continue to be high-risk.
Extra JPRT runs might be a good idea.
On Tue, Jun 23, 2009 at 07:51, Christos Zoulas <christos at zoulas.com> wrote:
> On Jun 23, 3:33pm, aph at redhat.com (Andrew Haley) wrote:
> -- Subject: Re: Review request for 5049299
> | I can debug this.
> | Please try first syscall(SYS_clone ...) to bypass the libc gubbins.
> | That might be all you need. If that doesn't help I'll have a look.
> | Isn't there some point at which you have to say to a Linux user "Your
> | system is simply misconfigured. Fix the overcommit parameter and this
> | problem will go away" ?
> Another thing to try is to add CLONE_VFORK to suspend the parent.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev