From owner-freebsd-hackers Mon Jul 19 11:42: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kronos.alcnet.com (kronos.alcnet.com [63.69.28.22]) by hub.freebsd.org (Postfix) with ESMTP id C77F414F19 for ; Mon, 19 Jul 1999 11:42:02 -0700 (PDT) (envelope-from kbyanc@alcnet.com) X-Provider: ALC Communications, Inc. http://www.alcnet.com/ Received: from kbyanc (ws-41.alcnet.com [63.69.28.41]) by kronos.alcnet.com (8.9.3/8.9.3/antispam) with SMTP id OAA29440; Mon, 19 Jul 1999 14:56:36 -0400 (EDT) From: "Kelly Yancey" To: "Dag-Erling Smorgrav" Cc: Subject: RE: Overcommit and calloc() Date: Mon, 19 Jul 1999 14:52:55 -0400 Message-ID: <002201bed217$e94beae0$291c453f@kbyanc.alcnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Dag-Erling Smorgrav [mailto:des@flood.ping.uio.no] > Sent: Monday, July 19, 1999 12:39 PM > To: Kelly Yancey > Cc: Dag-Erling Smorgrav; freebsd-hackers@freebsd.org > Subject: Re: Overcommit and calloc() > > > "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. > I guess I was looking at it from the commitment of memory point-of-view. Calloc() calls malloc() to get the memory (which will overcommit); calloc() then touches every page of the memory using bzero(). The memory itself will be committed. The only aspect of non-overcommit that it doesn't do is kindly tell the process if it couldn't touch every page, instead the overcommit model kills a process to reclaim pages so the bzero() will succeed (assuming we're not the unfortunate process :) ). You are absolutely right, calloc() doesn't act like a non-overcommit calloc() would, but it does in fact commit the memory. I don't know how many programs make use of calloc() but would not a more efficient algorithm be to better integrate it with malloc() such that if there is a fragment on the heap which can be used, bzero() it and return that, otherwise, simply call sbrk() and return that (since it is already zero'ed). Currently, in the event that malloc() simply returns newly sbrk()'ed memory, we unnecessarily zero it again. And yes, if the majority of people think this is worthwhile and I'm not just complete wrong here, then I'm glad to submit the patches. Kelly ~kbyanc@posi.net~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message