From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 10 15:42:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D79D1106566C for ; Thu, 10 Dec 2009 15:42:54 +0000 (UTC) (envelope-from nate@thatsmathematics.com) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 82C4B8FC12 for ; Thu, 10 Dec 2009 15:42:54 +0000 (UTC) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id nBAFgso07631; Thu, 10 Dec 2009 07:42:54 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id nBAFgrH05735; Thu, 10 Dec 2009 07:42:53 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Thu, 10 Dec 2009 07:42:53 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Linda Messerschmidt In-Reply-To: <237c27100912100723u77c5dd2udbcd3732ed9ee6a@mail.gmail.com> Message-ID: References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> <20091210145052.GX20668@cicely7.cicely.de> <237c27100912100723u77c5dd2udbcd3732ed9ee6a@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 15:42:54 -0000 On Thu, 10 Dec 2009, Linda Messerschmidt wrote: > Also... > > On Thu, Dec 10, 2009 at 9:50 AM, Bernd Walter wrote: >> I use fork myself, because it is easier sometimes, but people writing >> big programms such as squid should know better. >> If squid doesn't use vfork they likely have a reason. > > Actually they are probably going to switch to vfork(). They were > previously not using it because they thought there was some ambiguity > about whether it was going to be around long term. Well, the worst that would likely happen to vfork() is it would become an alias of fork(), and you'd be back to where you are now (or better if fork() were fixed in the meantime). I'd be more worried about the mysterious bugs which it's so easy to introduce with vfork() if you do anything at all nontrivial before exec() and accidentally touch the parent's memory. What about using posix_spawn(3)? This is implemented in terms of vfork(), so you'll gain the same performance advantages, but it avoids many of vfork's pitfalls. Also, since it's a POSIX standard function, you needn't worry that it will go away or change its semantics someday. > I actually am not a huge fan of vfork() since it stalls the parent > process until the child exec()'s. If you're doing so much work between vfork() and exec() that this delay is significant, then I would think you're really abusing vfork(). > To me, this case actually highlights why that's an issue. If the > explanation is that stuff is happening in the parent process between > fork() and the child's exec() causes the fragmentation, that's stuff > that would be deferred in a vfork() regime, with unknown potential > consequences. (At a minimum, decreased performance.) Not necessarily. In the fork() case, presumably copy-on-write is to blame for the fragmentation. In the vfork() case, there's no copy at all. -- Nate Eldredge nate@thatsmathematics.com