> -----Original Message-----
> From: Dag-Erling Smorgrav [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 19, 1999 12:39 PM
> To: Kelly Yancey
> Cc: Dag-Erling Smorgrav; [EMAIL PROTECTED]
> Subject: Re: Overcommit and calloc()
>
>
> "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.
>
I guess I was looking at it from the commitment of memory point-of-view.
Calloc() calls malloc() to get the memory (which will overcommit); calloc()
then touches every page of the memory using bzero(). The memory itself will
be committed. The only aspect of non-overcommit that it doesn't do is kindly
tell the process if it couldn't touch every page, instead the overcommit
model kills a process to reclaim pages so the bzero() will succeed (assuming
we're not the unfortunate process :) ).
You are absolutely right, calloc() doesn't act like a non-overcommit
calloc() would, but it does in fact commit the memory.
I don't know how many programs make use of calloc() but would not a more
efficient algorithm be to better integrate it with malloc() such that if
there is a fragment on the heap which can be used, bzero() it and return
that, otherwise, simply call sbrk() and return that (since it is already
zero'ed). Currently, in the event that malloc() simply returns newly
sbrk()'ed memory, we unnecessarily zero it again.
And yes, if the majority of people think this is worthwhile and I'm not
just complete wrong here, then I'm glad to submit the patches.
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
