Date: Wed, 13 Aug 1997 12:37:21 -0500 (EST) From: dyson@iquest.net To: djardine@hotmail.com (Douglas Jardine) Cc: freebsd-hackers@FreeBSD.ORG, djardine@hotmail.com Subject: Re: Memory management details Message-ID: <19970813173721.11238.qmail@iquest7.iquest.net> In-Reply-To: <19970813014802.27316.qmail@hotmail.com> from "Douglas Jardine" at Aug 12, 97 06:48:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970813173721.11238.qmail>