Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!agate!howland.reston.ans.net!news.sprintlink.net!helena.MT.net!nate From: nate@trout.sri.MT.net (Nate Williams) Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux Subject: Re: FreeBSD page better than Linux? Date: 6 Sep 1995 05:41:50 GMT Organization: SRI Intl. - Montana Operations Lines: 38 Message-ID: <42jcau$kf9@helena.MT.net> References: <42cnbp$mit@blackice.winternet.com> <42iejc$hkl@agate.berkeley.edu> <42iicc$hlk@news.jf.intel.com> Reply-To: "Nate Williams" <nate@sneezy.sri.com> NNTP-Posting-Host: trout.sri.mt.net Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:5472 comp.os.linux:58849 In article <42iicc$hlk@news.jf.intel.com>, Mike Haertel <haertel@ichips.intel.com> wrote: >In article <42iejc$hkl@agate.berkeley.edu>, >>FreeBSD seems to need/require a lot more swap space than Linux does. >If this is true, does anyone have any idea to what extent it might be >because FreeBSD is still using the ancient powers-of-two Caltech malloc? Some of the problems are definitely a problem of the fast but non-effecient BSD malloc, but the primary reason for requiring more VM is the system was designed that way. By agressively paging everything to disk we keep the amount of free memory available high for use by programs AND the disk cache. Note, I'm no VM expert, but this strategy seems to work very well, with no noticable loss of performance, but rather the opposite. Again, it does require more VM room up front, but once the system has been running for about 15 minutes under typical loads the amount of VM used stays fairly static. However, replacing the stock BSD (Caltech) malloc has been bandied about quite a few times in the past, but so far no resolution has been made. So far the best implementation with an acceptable copyright has been Doug Lea's (sp?) malloc implementation. Many folks have been going through and fixing any program which rely on the current behavior of malloc returning bzero memory. Nate -- nate@sneezy.sri.com | Research Engineer, SRI Intl. - Montana Operations nate@trout.sri.MT.net | Loving life in God's country, the great state of work #: (406) 449-7662 | Montana. Wanna go fly fishing? I don't charge or home #: (406) 443-7063 | feed you, but I do know the area pretty well.