> > On the other hand, I find the discussion about the merits of overcommit > and the (albeit not always in-depth) explanations of the FreeBSD VM system > educational. It would be nice if would could just extract the small amount > of signal from this discussion and put it into documentation somewhere. > Also, it has got me thinking: does FreeBSD overcommit memory allocated by > calloc()? Seems that it would be difficult since the page would > have had to > have been touched in order be zeroed, but I was curious. >
I'm afraid my question got lost amongst the see of overcommit messages. :) I was curious if calloc() was overcommitted also? Or is it more fundamental than that and the kernel always overcommits memory, which processes claim via sbrk, but which, when finally touched by the app, the kernel fills with a zero'ed page. If my scenario is correct, what affect does our malloc() algorithm have, if any...in other words, is there any way to reclaim memory which was returned to the heap via free(), but which malloc() can't sbrk back to the system? Does it matter? The scenario I think of is a process malloc()'ing a large amount of memory (which is implemented by increasing the process' address space via sbrk), then malloc()'ing another chunk of memory (again, sbrk'ing). Finally, freeing the memory allocated via the first call to malloc(). Now there is a large hole in the process' address space, which presumably will be backed by swap when in fact it is useless. I can't think of any way around that, nor can I imagine it is that great of a problem, but then again, I don't know everything :) I was curious what some of the gurus thought. Thanks, Kelly ~kby...@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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
