Date: Tue, 20 Jul 1999 13:28:21 -0400 From: "Kelly Yancey" <kbyanc@alcnet.com> To: <crandall@matchlogic.com> Cc: <freebsd-hackers@freebsd.org> Subject: RE: Overcommit and calloc() Message-ID: <005101bed2d5$433a16e0$291c453f@kbyanc.alcnet.com>
next in thread | raw e-mail | index | archive | help
> From: Charles Randall > >I have another post on this list which begs the question: if memory given > >to us from 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 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?005101bed2d5$433a16e0$291c453f>