From owner-freebsd-hackers Mon Jul 19 23:59:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 1A7FB15200 for ; Mon, 19 Jul 1999 23:59:15 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id JAA22179; Tue, 20 Jul 1999 09:53:24 +0300 (EEST) (envelope-from will) To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Cc: hackers@freebsd.org Subject: Re: Overcommit and calloc() References: <001f01bed205$e8aeecc0$291c453f@kbyanc.alcnet.com> From: Ville-Pertti Keinonen Date: 20 Jul 1999 09:53:24 +0300 In-Reply-To: des@flood.ping.uio.no's message of "19 Jul 1999 19:41:31 +0300" Message-ID: <86zp0rizh7.fsf@not.demophon.com> Lines: 21 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG des@flood.ping.uio.no (Dag-Erling Smorgrav) writes: > "Kelly Yancey" writes: > > Ahh...but wouldn't the bzero() touch all of the memory just allocated > > functionally making it non-overcommit? > > No. If it were an "non-overcomitting malloc", it would return NULL and > set errno to ENOMEM, instead of dumping core. It won't dump core. If it isn't the biggest process, it'll simply succeed, but somebody else is killed. If it's the biggest process, it'll die with SIGKILL without dumping core. There *are* systems that kill "random" processes when swap runs out, presumably when they need to actually get pages that aren't available. FreeBSD is not one of them. Overcommit still has nothing to do with malloc. Either the *system* is overcommitted or it isn't - per-process overcommitment is irrelevant, as is the way memory has become overcommitted. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message