> -----Original Message-----
> From: Dan Nelson [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 19, 1999 12:55 PM
> To: Dag-Erling Smorgrav
> Cc: Kelly Yancey; [EMAIL PROTECTED]
> Subject: Re: Overcommit and calloc()
>
>
> In the last episode (Jul 19), Dag-Erling Smorgrav said:
> > "Kelly Yancey" <[EMAIL PROTECTED]> 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
~[EMAIL PROTECTED]~
FreeBSD - The Power To Serve - http://www.freebsd.org/
Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
