Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!gatech!news.mathworks.com!news.PBI.net!cbgw3.att.com!nntphub.cb.lucent.com!news From: "John S. Dyson" <dyson@inuxs.att.com> Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc Subject: Re: Curious about *BSD History Date: Tue, 02 Jul 1996 14:29:34 -0500 Organization: Lucent Technologies, Columbus, Ohio Lines: 84 Message-ID: <31D9789E.41C67EA6@inuxs.att.com> References: <4k1nue$lm8@orb.direct.ca> <31D0A2C9.72741EA8@lambert.org> <4qs2ag$bg0@pier2.bayarea.net> <31D29460.41C67EA6@inuxs.att.com> <4rbql3$ges@pier2.bayarea.net> NNTP-Posting-Host: dyson.inh.lucent.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (X11; I; FreeBSD 2.1-STABLE i386) CC: dyson@iquest.net Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:22642 comp.unix.bsd.netbsd.misc:3905 Jason R. Thorpe wrote: > > In article <31D29460.41C67EA6@inuxs.att.com>, > John S. Dyson <dyson@inuxs.att.com> wrote: > > >> Ick! Why is there i386 MMU-specific stuff (or assumptions) in the > >> FreeBSD VM code? All of that should live completely in pmap! > >> > >Ick!!! Why is there i386 MMU-specific stuff in the NetBSD VM > >code? (In vm_glue.c for example :-)). Please refer to > >the ifdefs... > > Granted, NetBSD has a few i386 and pc532 #ifdef's in the MI vm code. > However, those are XXX'd, and will eventually go away. > > However, the notion of having to write an i386 MMU emulator for the > PowerPC seems ... wrong. > FreeBSD's VM system requires no such thing either (you must be thinking of Linux.) In order to do paging statistics, one needs to emulate the modify &| reference bits. Some architectures hove none, and the statistics are gathered by doing page protection games. That would be all in the machine dependent pmap layer, just like NetBSD. We have spent significant amounts of effort on the pmap code, but that is not the VM system at large, it is support code providing the interface to the machine mmu mechanism itself. At one time we might have made some assumptions about page table pages being mapped or whatever, but those days are long gone. Those assumptions were no worse than the pagemove() bogosity (which is a bit of a layering violation) that we no longer have in FreeBSD. We aren't just trying to make things work, we are trying to make things work very very well. > > I was simply reacting to Terry's comment that he wanted to do so so he could > more easily track FreeBSD's VM changes. Why that would be necessary > only leads me to believe that there are more assumptions than necessary. > The FreeBSD VM system makes few (if any) more assumptions about the underlying hardware than NetBSD. It is possible that a bogus hardware implementation would impact performance, but then that is *still* the same as the situation with NetBSD. Tracking the FreeBSD VM system wouldn't be that hard, and porting it isn't brain surgery. IMO, the only thing that would keep someone from doing it is that it is documented less than the original 4.4 stuff is. Actually, the FreeBSD VM scheme is simplified in certain areas by removing unneeded cruft (some of it was inspired by Hibler's comments.) Complications were added to make it work much better. We don't do ANY pte manipulations outside of pmap.c (unlike NetBSD). We use the pmap_enter/pmap_remove paradigm just as the original code. FreeBSD has added optional pmap entry points to support microcoded TLB's better. An old example that you would find in NetBSD code is "pmap_copy". Note that it isn't implemented in the NetBSD i386 VM system, but it is implemented in FreeBSD. We have other LL optimization entry points that are purely optional to implement. Other FreeBSD improvements include a much better pageout daemon (uses the pmap interface, so is machine independent), the swap space growing problem is now non-existant (machine independent), merged VM/Buffer cache (machine independent -- except we don't support DEV_BSIZE != 512 right now.) We have done machine dependent optimizations (some of which are optional low level routines called from the upper level MI code.) For example, we have much better management of page table pages, a totally reworked pmap module (we even removed the ugly inline asms), and other optimizations have improved FreeBSD-current fork/exit time to about 500usecs (from 1200usecs on FreeBSD 2.1.x or 1400usecs on NetBSD) on a P5/166. There are some more machine dependent optimizatins (in the MD files) that will bring that time down to about 480usecs, and cached disk reads to about 60-70 MBytes per second!!! So, we do machine dependent optimizations, but they are in the machine dependent places. We also do machine independent optimizations, and those are useful on many architectures. John