:> here is a (rough) draft of the design for the new VM, as
:> discussed at UKUUG and OLS. The design is heavily based
:> on the FreeBSD VM subsystem - a proven design - with some
:> tweaks where we think things can be improved.
:>
:> Can the differences between your system and what FreeBSD has be
:> isolated or contained
:
:You're right, the differences between FreeBSD VM and the new
:Linux VM should be clearly indicated.
:
:> I ask this because the FreeBSD VM works _very_ well compared to
:> recent linux kernels; if/when the new system is implement it
:> would nice to know if performance differences are tuning related
:> or because of 'tweaks'.
:
:Indeed. The amount of documentation (books? nah..) on VM
:is so sparse that it would be good to have both systems
:properly documented. That would fill a void in CS theory
:and documentation that was painfully there while I was
:trying to find useful information to help with the design
:of the new Linux VM...
:
:regards,
:
:Rik
Three or four times in the last year I've gotten emails from
people looking for 'VM documentation' or 'books they could read'.
I couldn't find a blessed thing! Oh, sure, there are papers strewn
about, but most are very focused on single aspects of a VM design.
I have yet to find anything that covers the whole thing. I've written
up an occassional 'summary piece' for FreeBSD, e.g. the Jan 2000 Daemon
News article, but that really isn't adequate.
The new Linux VM design looks exciting! I will be paying close
attention to your progress with an eye towards reworking some of
FreeBSD's code. Except for one or two eyesores (1) the FreeBSD code is
algorithmically sound, but pieces of the implementation are rather
messy from years of patching. When I first started working on it
the existing crew had a big bent towards patching rather then
rewriting and I had to really push to get some of my rewrites
through. The patching had reached the limits of the original
code-base's flexibility.
note(1) - the one that came up just last week was the O(N) nature
of the FreeBSD VM maps (linux uses an AVL tree here). These work
fine for 95% of the apps out there but turn into a sludgepile for
things like malloc debuggers and distributed shared memory systems
which want to mprotect() on a page-by-page basis. The second eyesore
is the lack of physically shared page table segments for 'standard'
processes. At the moment, it's an all (rfork/RFMEM/clone) or nothing
(fork) deal. Physical segment sharing outside of clone is something
Linux could use to, I don't think it does it either. It's not easy to
do right.
-Matt
Matthew Dillon
<dillon@backplane.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:13 EST