Ahh...but wouldn't the bzero() touch all of the memory just allocated functionally making it non-overcommit? I realize that technically it isn't the same since although calloc() would ensure the memory actually was committed (again, since the bzero() touches all the pages), if there weren't enough pages free then a random process would still be killed rather than returning null. Believe me, I'm not trying to start that war again :) I'm just pointing out that while technically it is still overcommit, it will touch the pages ensuring that the memory does in fact exist (is committed). Perhaps this is why I've always heard we should avoid calloc() because it is 'slow'?
Thanks for the great feedback, I should kick myself for now digging my hands in the mud myself (I assumed it was more complicated than that :) ). Kelly ~kby...@posi.net~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD > -----Original Message----- > From: Dag-Erling Smorgrav [mailto:d...@flood.ping.uio.no] > Sent: Monday, July 19, 1999 12:07 PM > To: Kelly Yancey > Cc: hack...@freebsd.org > Subject: Re: Overcommit and calloc() > > > "Kelly Yancey" <kby...@alcnet.com> writes: > > I'm afraid my question got lost amongst the see of overcommit > messages. :) > > I was curious if calloc() was overcommitted also? > > Here's our calloc() implementation: > > void * > calloc(num, size) > size_t num; > register size_t size; > { > register void *p; > > size *= num; > if ( (p = malloc(size)) ) > bzero(p, size); > return(p); > } > > so the answer is yes, it overcommits, but the bzero() may cause the > system to run out of swap. > > DES > -- > Dag-Erling Smorgrav - d...@flood.ping.uio.no > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
