From owner-freebsd-hackers@FreeBSD.ORG Wed May 27 13:10:32 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 82522106566C for ; Wed, 27 May 2009 13:10:32 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 40BFB8FC12 for ; Wed, 27 May 2009 13:10:32 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (cm-84.215.252.34.getinternet.no [84.215.252.34]) by smtp.des.no (Postfix) with ESMTP id 5F08B6D41D; Wed, 27 May 2009 15:10:31 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 533E0844C2; Wed, 27 May 2009 15:10:31 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: yuri@rawbw.com References: <4A14F58F.8000801@rawbw.com> <4A1594DA.2010707@rawbw.com> Date: Wed, 27 May 2009 15:10:31 +0200 In-Reply-To: <4A1594DA.2010707@rawbw.com> (yuri@rawbw.com's message of "Thu, 21 May 2009 10:52:26 -0700") Message-ID: <86ljoig08o.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Nate Eldredge , freebsd-hackers@freebsd.org Subject: Re: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls? 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: Wed, 27 May 2009 13:10:32 -0000 Yuri writes: > I don't have strong opinion for or against "memory overcommit". But I > can imagine one could argue that fork with intent of exec is a faulty > scenario that is a relict from the past. It can be replaced by some > atomic method that would spawn the child without ovecommitting. You will very rarely see something like this: if ((pid =3D fork()) =3D=3D 0) { execve(path, argv, envp); _exit(1); } Usually, what you see is closer to this: if ((pid =3D fork()) =3D=3D 0) { for (int fd =3D 3; fd < getdtablesize(); ++fd) (void)close(fd); execve(path, argv, envp); _exit(1); } ...with infinite variation depending on whether the parent needs to communicate with the child, whether the child needs std{in,out,err} at all, etc. For the trivial case, there is always vfork(), which does not duplicate the address space, and blocks the parent until the child has execve()d. This allows you to pull cute tricks like this: volatile int error =3D 0; if ((pid =3D vfork()) =3D=3D 0) { error =3D execve(path, argv, envp); _exit(1); } if (pid =3D=3D -1 || error !=3D 0) perror("Failed to start subprocess"); DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no