Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!sol.ctr.columbia.edu!hamblin.math.byu.edu!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Newsgroups: comp.os.386bsd.bugs Subject: Re: Mixing 4k and 8k filesystems Date: 21 Nov 1993 09:12:36 GMT Organization: Weber State University, Ogden, UT Lines: 41 Message-ID: <2cnbe4$rbm@u.cc.utah.edu> References: <35346@ksr.com> <2cc4sd$6s6@u.cc.utah.edu> <CGD.93Nov19000053@eden.CS.Berkeley.EDU> NNTP-Posting-Host: cs.weber.edu Terry>>NetBSD does not have this problem because they have unified the VM and Terry>>buffer cache (at least on current). Chris>no we don't. we just do 'the standard thing' with buffer cache pages, Chris>that meaning "we allocate a certain number of them, then move them around Chris>depending on where they're needed. Sorry; I discussed it offline with a NetBSD'er, and it seems I was being a bit more lax with the term "unified" than I should have -- I didn't intend to imply that there was runtime competition in a common pool (which would lead to the well know SVR4 race conditions and the ability of one program to "piss all over the cache"). Terry>>FreeBSD doesn't have this problem because of the way page reclamation is Terry>>done (at least on current). Chris>actually, they don't have it (from looking at their code and from Chris>reading the mail messages that come over the freebsd mailing lists, Chris>etc.) because they make the kernel memory map large enough that Chris>"fragmentation is not a problem," or at least that's what somebody Chris>(i think davidg) said... given the fact that they reclaim sub-page Chris>buffers, they could make the problem *worse* but for the larger Chris>kmem map. Uh... providing a large space *is* the way page reclaimation is done. 8-). I actually don't think sub-page buffer reclaimation is done, at least not the way you imply, in the FreeBSD system; you could think of the larger kmem map as an intermediate "second chance" cache. Of course, you'd be better off discussing it with David Greenman or Bruce Evans, since I'm only an observer of the VM in both camps (having written my own -- I think memory overcommit is absolutely stupid, and won't tolerate ETXTBSY on my machine; I use NFS too much). 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.