*BSD News Article 50299


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.