Date: Tue, 20 Jul 1999 10:53:26 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Kelly Yancey" <kbyanc@alcnet.com> Cc: <crandall@matchlogic.com>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: RE: Overcommit and calloc() Message-ID: <199907201753.KAA06000@apollo.backplane.com> References: <005101bed2d5$433a16e0$291c453f@kbyanc.alcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think this would be a waste of time. As I have said, very few
large allocations use calloc(). Nearly all small allocations come
off the heap. The cost of adding the complexity to calloc to avoid
zeroing the data is not going to be worth the minor (and unnoticeable)
improvement in performance that you reap from it. Right now malloc/calloc
add new blocks to the heap in chunks and while they may know that a page
is zero on allocation, once the first small bit has been removed from
the heap they have no idea that the remainder is still zero. Making them
knowledgeable of that will simply make the critical path more costly and
probably end up in reducing your overall performance.
-Matt
Matthew Dillon
<dillon@backplane.com>
:
: Specifically, if there are no blocks on the heap that can be re-used by
:malloc(), it calls sbrk() to extend the process' address space. sbrk()
:always returns memory that the kernel has already gone through the effort of
:zero'ing...why do it again? I am thinking about making calloc() more
:intellegent like malloc(): if it re-uses a free()'ed memory block, then it
:has to bzero() it (exactly like it does now), if it has to sbrk() then it
:can skip the bzero() step and save some clock cycles. I'm expecting that in
:addition of gaining clock cycles from not zeroing the memory twice, the fact
:that calloc() won't have to touch all newly allocated pages would reduce the
:amount of work by the VM system and give another little performance boost.
:
: On recent thought though, I seem to recall having read in the 4.4BSD
:Daemon book that having the kernel zero memory is not the preferred
:practice, but present because when they tried to stop many progrems dies
:which assumed memory was initialized to zero. If I am remembering that
:correctly, then, the only real concern is that one day we may want to kernel
:to stop zeroing pages, in which case the extra logic in calloc() would be
:for nought.
: Really the jist of the changes I'm looking to make are to use the fact
:that the kernel is already zeroing pages to optimize the calloc()
:implementation. If this ever changes, then the optimization would go away.
:
: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907201753.KAA06000>