From owner-freebsd-hackers  Wed Aug 13 10:38:40 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id KAA14888
          for hackers-outgoing; Wed, 13 Aug 1997 10:38:40 -0700 (PDT)
Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA14883
          for <freebsd-hackers@FreeBSD.ORG>; Wed, 13 Aug 1997 10:38:38 -0700 (PDT)
From: dyson@iquest.net
Received: (qmail 19158 invoked from network); 13 Aug 1997 17:37:22 -0000
Received: from iquest7.iquest.net (206.53.230.110)
  by iquest3.iquest.net with SMTP; 13 Aug 1997 17:37:22 -0000
Received: (qmail 11242 invoked by uid 4420); 13 Aug 1997 17:37:21 -0000
Message-ID: <19970813173721.11238.qmail@iquest7.iquest.net>
Subject: Re: Memory management details
To: djardine@hotmail.com (Douglas Jardine)
Date: Wed, 13 Aug 1997 12:37:21 -0500 (EST)
Cc: freebsd-hackers@FreeBSD.ORG, djardine@hotmail.com
In-Reply-To: <19970813014802.27316.qmail@hotmail.com> from "Douglas Jardine" at Aug 12, 97 06:48:02 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> Hi,
> 
> I had some questions regarding Memory allocation/management in
> FreeBSD/4.4BSD.  I was hoping some here would be able to help
> me out.
> 
> 1)The mail archives seem to indicate that the latest versions of
>   FreeBSD use a zone memory allocator which replaced the 4.4BSD
>   buddy system allocator. Is this correct? 
>
We are using the zone allocator as an adjunct to the existing
buddy allocator.  Each is good in it's own ways, and it is likely
that a few more data types will be moved to "zone."  However, I
don't see the malloc allocator going away entirely.

> 
> 2)Is FreeBSD considering moving to a more simplified pmap module?
>   Since it is customized to run only on i386 architeure, there
>   doesn't seem to be any need for maintaining whatever extra fat
>   the pmap module may have.
>
Many of the pmap entry points are optional, and the pmap module
could be considerably simplified at the expense of scalability.
That isn't to say that a well-structured redesign isn't in order :-).

> 
> 3)FreeBSD uses Global-LRU for its page replacement. Is there any
>   project in the FreeBSD community working towards a working-set
>   type model?
>
The VM people on FreeBSD (if religious at all) are not in favor
of a working-set model.  We do have trimming based upon working set,
but it appears that most working set implementations appear to have
more performance problems than we have.  If there is some convincing
evidence that a working set model would give us advantage in some way,
I am sure that we would listen and try to participate.

> 
> 4)Or for that matter a project to add "swap files"? What is the
>   maximum number of swap partitions allowed by the architecture?
>
That is a "bounded" project, that is pretty well understood, but just
not done yet.  I don't think that anyone has made any progress.  Not
to say that it is easy to do "right", but developing a properly
functioning swap on/ swap off a file is less risky than any of the above.
(The ONLY reason that we don't support swap-on directly, is that I don't
want to see it until we get a swap-off also.)  The swap-off is not
trivial, but isn't brain-surgery either.

John