*BSD News Article 27548


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