Virtual memory consumption (both user and kernel) in modern CURRENT

[Kris Kennaway]

On Thu, Feb 16, 2006 at 08:23:50PM -0500, Mike Jakubik wrote:
> Giorgos Keramidas wrote:
> >On 2006-02-16 12:35, Brian Candler <B.Candler at pobox.com> wrote:
> >  
> >>On Wed, Feb 15, 2006 at 11:11:49AM +0800, David Xu wrote:
> >>    
> >>>>1) Is it normal that virtual memory size for almost every non-kernel
> >>>>process
> >>>>  is close to 50Mb now:
> >>>>
> >>>>   ftp://external.atlantis.dp.ua/FreeBSD/CURRENT/top.txt
> >>>>
> >>>>  Is it miscalculation or real growth of virtual address space?
> >>>>        
> >>>I believe this is the new malloc code in libc, I am seeing this on my
> >>>Athlon64 machine, now it likes swap memory, in the old days, it seldom
> >>>touched it.
> >>>      
> >>IIRR, the new malloc grabs 32MB immediately. However, I'd hope that 
> >>doesn't
> >>mean that 32MB of pages are actually touched, and then get swapped out to
> >>disk. If it does, I'm staying on FreeBSD 6.0 :-)
> >>    
> >
> >I don't think so.
> >
> >At least, not unless you are using the debugging features of malloc(),
> >which can result in all pages getting touched (i.e. if the "J" option is
> >enabled, to set all newly-allocated bytes to 0xa5, which is very helpful
> >when trying to catch accesses to uninitialized pointers).
> >
> >It's all a matter of what you are prepared to trade-off and why, I guess :)
> >  
> 
> And what am i trading off here? I have "/etc/malloc.conf@ -> ajz" and my 
> memory usage has gone up the roof. My system used to be swap free, and 
> now its swapping over 40 MB. Can someone explain to me why this new 
> malloc is better? I don't see any speed improvements.

It's a couple of orders of magnitude faster for threaded binaries.
See earlier posts by the author for extensive discussion.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20060216/de699680/attachment.bin