Date: Mon, 19 Jul 1999 16:14:29 -0400 From: "Kelly Yancey" <kbyanc@alcnet.com> To: "Dan Nelson" <dnelson@emsphone.com> Cc: <freebsd-hackers@FreeBSD.ORG> Subject: RE: Overcommit and calloc() Message-ID: <002501bed223$4ea86660$291c453f@kbyanc.alcnet.com> In-Reply-To: <19990719115450.A45503@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Dan Nelson [mailto:dnelson@emsphone.com] > Sent: Monday, July 19, 1999 12:55 PM > To: Dag-Erling Smorgrav > Cc: Kelly Yancey; freebsd-hackers@FreeBSD.ORG > Subject: Re: Overcommit and calloc() > > > In the last episode (Jul 19), Dag-Erling Smorgrav said: > > "Kelly Yancey" <kbyanc@alcnet.com> 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. > > It should be possible to modify calloc to trap signals, then bzero. If > bzero faults, you free the memory and return NULL. > > No, wait. You can't trap SIGKILL. How about this. mmap() some > anonymous memory MAP_SHARED, fork a child to bzero it. If the child > dies, unmmap and return NULL. If the child succeeds, use the memory. > This memory won't be freeable with malloc(), though. > Hrm. I'm not actually trying to get my system to not overcommit memory. I like overcommit. Besides, every process would have to trap SIGKILL (if you even could) to simulate a non-overcommit system because any process could be killed, not just the one requesting the memory, right? Really, I was just on an educational quest. I was curious to exactly how calloc() was implemented and what affect that had on our overcommit policy. DES was nice enough to show me that calloc() is just a malloc()+bzero() so effectively, the memory gets 'committed' because all of the pages are touched immediately after the malloc(). Whether or not a process get's shot is another matter entirely. :) 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. The real question is, how many? A quick scan (not exact) of the number of times calloc() is called yields: $ cd /usr/src $ t=0; grep -c -h -R "calloc" * | while read n; do let t+=$n; echo $t; done | tail -1 828 $ t=0; grep -c -h -R "malloc" * | while read n; do let t+=$n; echo $t; done | tail -1 11380 (of course, they each are a little high due to comments and the actual function definitions themselves; cavaet emptor) So calloc() is only used about 1/14th as often as malloc(), and considering many of those calloc() calls would still be serviced the same was a malloc() (reusing memory already on the heap and bzero()'ing it), I'm not 100% sure if the added complexity if worth the performance improvement. If it is, I'de be glad to "whip" some patches up for it (it really shouldn't be too hard). 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?002501bed223$4ea86660$291c453f>