Date: Mon, 19 Jul 1999 13:39:54 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Charles Randall <crandall@matchlogic.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: RE: Overcommit and calloc() Message-ID: <199907192039.NAA99539@apollo.backplane.com> References: <64003B21ECCAD11185C500805F31EC0302D75907@houston.matchlogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907192039.NAA99539>