Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!noc.near.net!news.delphi.com!usenet From: John Dyson <dysonj@delphi.com> Newsgroups: comp.os.386bsd.development Subject: Re: Could the BSD 4.4 Lite be a new beginning? Date: Fri, 18 Feb 94 20:21:59 -0500 Organization: Delphi (info@delphi.com email, 800-695-4005 voice) Lines: 122 Message-ID: <hq5JeSv.dysonj@delphi.com> References: <HSU.94Feb14043905@laphroaig.cs.hut.fi> <R60q1p-.dysonj@delphi.com> <MYCROFT.94Feb17180243@duality.gnu.ai.mit.edu> NNTP-Posting-Host: bos1b.delphi.com X-To: Charles Hannum <mycroft@duality.gnu.ai.mit.edu> Charles Hannum <mycroft@duality.gnu.ai.mit.edu> writes: >In his previous post, John Dyson brought up a few points that I would >like to expand on: > > optimized pmap code, > >Except for two uses of i386 assembler code which in practice make >little difference, the one in NetBSD-current is faster, and in >particular does fewer TLB flushes. The new pmap code is *significantly* improved over the *old* pmap code which is essentially what NetBSD is using ( some uninspired tweaks.) The tlbflush doesn't cost really that much and in fact the new code is faster (try the code Charles, before making out-of-hand statements.) The pmap code is really a *VERY* minor part of our VM improvements anyway. Our pmap code (actually changes) supports fully the concept of page-table-paging and is faster. The 1.1 version of the code (about to be released and in current) has been improved upon further, DG and myself have seen really significant improvements, beyond anything else to date. (BTW, pmap is a *small* *small* part of the performance puzzle.) The biggest gains can be gotten by restructuring the rest of the VM system. Look out for 1.2 -- it will *even* be better.... I am currently running about 20% of the changes for 1.2, and it works well so far. (and screams.) > multi-page cluster pageins, > >You mean `pageouts', I think, and Mike Hibler's VM code for 4.4 does >this, and I dare say has been more thoroughly tested. It seems a >better choice to me for us to wait for that code to be available. Huh? No I said pageins. Have you even bothered to look at the code? It is obvious to anyone as experienced as I assume that you are that the code in the VM system has changed and been improved significantly and there is code (significant amounts) to support clustered pageins. The 'dare say' doesn't seem to come from someone to be trusted considering the misinformation or assumption made that I did not know the difference between pageins and pageouts!!!!! > and our if_ed driver, written by our team member, David Greenman, > is *very* reliable and attains THE ethernet bandwidth. > >Before he was officially(?) a FreeBSD `team member', he also donated >this code to NetBSD. We have added multicast support and cleaned this >up a bit. In addition, `our' if_ep (3COM 3C509 driver) has been >clocked at full ethernet bandwidth, and works reliably in NetBSD. In fact, I was an alpha-tester for his if_ed driver and saw the initial simple-minded first phase hack, the total conceptual rewrite throwing away the original code -not even looking at it- and produced the *most* robust driver for ethernet cardS that I have ever heard of. It is great because it *really* works for so many card types. I had *much* of the VM code written before joining the FreeBSD team, and in fact have not been considered a CORE team member until a week or so ago. I made the changes to the VM code to produce a *robust* implementation because my A** is on the line to get a related product out. I 'dare say' that I would not trust any operating system whose VM code code is very fragile. That is the reason that FreeBSD decided to take on my code (I did not even lobby strongly for it, I just wanted something to work for me.) I realize that NetBSD would have problems integrating the new very improved FreeBSD MACH-based VM system because of some very subtile (but major) improvements to the pmap and other layers. I am willing to help, but realize that closed-mindedness sometimes prevails. FreeBSD is going to be running in a difficult mission-critical environment, and if there are problems, they will be fixed post-haste. I suggest that before making a decision on any operating system, really look at it. Off-the-cuff judgements by people that have been pubescent probably for half the time that many of us have been programming are not worth much. I am *VERY* willing to take constructive comments on the new VM system as a whole, and *VERY* willing to accept suggestions for improvement. The 1.1 code is frozen, and the 1.2 code is in the works. Remember, we are really improving the VM code and solicit any constructive comment. To sum up my response to Charles' comments: The FreeBSD pmap code is still in flux, already I have a *new* version. The tlbflush change only makes about a 10% difference (which is vastly overshadowed by other enhancements that we have made.) We have a new change for 1.2 that already improves the most common VM operations by 3X!!!!! I measure 4X and DG measures 3X. We do support clustered pageins and do bypass the buffer cache. If 4.4 has good ideas, we will integrate them with ours, then we will have the best of both worlds. Remember, the changes that we have made to the VM system do not affect the API at all!!!!! So anyone running on other BSD variants might give us a try. Being honest, though unless you are a really experienced kernel hacker, wait until the release comes out. The upgrade procedures can be tricky and the automated procedures are much safer. One more thing, re: clustered pageouts... there is little need on our code, because we do get practically disk transfer rate bandwidth already. I would not have sent this message except the tone of Charles' comments was not respectful and I would not have commented negatively publically about his groups achievments (multi-platform.) We will probably go multi-platform when the improved VM code and other things are *fully* included. If anyone wants to correspond, mail me at 'dyson@implode.root.com' and any ideas that are submitted and included will get proper attribution. Remember, FreeBSD is being used in *real* work and my A** is really on the line. IT WILL/DOES WORK!!!! Anyone who has directly worked with me on BSD has usually been pleasantly suprised with how easy I am to get along with. Charles, next time that you have technical questions that you cannot answer, just talk to me... I am really very nice... (1-317-547-8347). John Dyson dyson@implode.root.com