From owner-freebsd-hackers Mon Jul 19 13:40:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id F00BD14E63 for ; Mon, 19 Jul 1999 13:40:28 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA99539; Mon, 19 Jul 1999 13:39:54 -0700 (PDT) (envelope-from dillon) Date: Mon, 19 Jul 1999 13:39:54 -0700 (PDT) From: Matthew Dillon Message-Id: <199907192039.NAA99539@apollo.backplane.com> To: Charles Randall Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: RE: Overcommit and calloc() References: <64003B21ECCAD11185C500805F31EC0302D75907@houston.matchlogic.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :From: Kelly Yancey [mailto:kbyanc@alcnet.com] :>I have another post on this list which begs the question: if memory given :>to us fro sbrk() is already zeroed, why zero it again if we don't have :>too.... if we make calloc() smarter, we could save come clock cycles. : :Because the memory returned from malloc() might be from a previous :malloc()/free() and may be dirty. : :Charles malloc() uses madvise( ... MADV_FREE) heavily in order to reduce the number of page faults that need to be taken through the course of a program's operation. MADV_FREE is an advisory free that causes FreeBSD to mark the underlying page(s) clean and to free any associated swap backing store. The kernel avoids actually freeing the page until it needs the memory, and the process can re-dirty the page to keep it. No new page-faults occur if the kernel has not reclaimed the page at the time the process reuses it. If the kernel reclaims the page first, the kernel replaces it with zero-fill. If the process reclaims the page first, the page's previous contents (considered to be 'garbage') are retained. Thus, calloc() cannot under normal circumstances assume that the data buffer returned by malloc() is already clear. Since calloc() is not usually used to allocate large chunks of memory, this isn't a problem. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message