Date: Mon, 1 Mar 1999 16:10:07 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: dcs@newsguy.com (Daniel C. Sobral) Cc: jgrosch@mooseriver.com, rab@pike.cdrom.com, Dave@Yost.com, freebsd-advocacy@FreeBSD.ORG Subject: VM notes Message-ID: <199903012110.QAA24626@y.dyson.net> In-Reply-To: <36DA4F25.951D91E4@newsguy.com> from "Daniel C. Sobral" at "Mar 1, 99 05:26:13 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel C. Sobral said:
> Josef Grosch wrote:
> >
> > FreeBSD has a superior VM and network subsystem. I'll try and find the post
> > that Matt Dillon sent to hackers several weeks ago. In this post he
> > analyzed the Linux VM system and explained why FreeBSD is better.
>
> Here it is.
>
....
>
> -Matt
>
> Matthew Dillon
> <dillon@backplane.com>
I do like Matt's review. IMO, the FreeBSD VM code started with
a very soundly designed (but in-need-of-productizing) VM concept
from the MACH project. What DG and I (plus others) did was to
clean-up alot of the chaffe, rework the parts that were just
broken, and improve some of the algorithms (e.g. paging, collapsing,
etc.)
In the case of the L-word, it would have been best to stand-back, and
review what is needed in a VM system, and redesign from scratch.
The really bad things about the FreeBSD VM code have to do with issues
such as the pmap and VM layering being in slightly the wrong place. In
a sense, it seems that Linux VM takes a totally opposed approach from the
MACH ancestory.
Doing it all over again, I would put MORE machine dependent bits into
pmap, and move the layering upwards. Also, I would just "punt" and produce
three flavors of pmap abstractions ((2,3,4 level) PTE, TLB, and inverse PTE.)
So, my VM code would look like this:
Upper level VM -- Page datastructure abstraction -- hardware abstraction.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Today's pmap.
In some machines, the page datastructure abstraction -- hardware abstraction,
might be fairly simple, because microcode does alot of the work. The key
to this is to design the upper level VM to support optimizations based upon
the three major schemes. Some of the optimizations would be ifdefed or
stubbed, but the VM code itself would be entirely the same.
I suspect that with proper design, the additional overhead would be nil, and
more effort could be placed on optimization for multiple architectures. The
total effect would be to see a net improvement in performance over more
architectures as the project evolves.
--
John | Never try to teach a pig to sing,
dyson@iquest.net | it makes one look stupid
jdyson@nc.com | and it irritates the pig.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903012110.QAA24626>