Slashdot Mirror

← Back to Stories (view on slashdot.org)

FreeBSD VM Design

Posted by Nik on from the so-that's-how-it's-done dept.

Over at DaemonNews is an excellent explanation of the FreeBSD VM design, from Matt Dillon, who's been doing a great deal of work on it recently. It's rare to see good descriptions of the internals (or parts of the internals) of any OS OS (that's "Open Source Operating System") so this is particularly welcome. As is customary, there are a number of other excellent articles over at DaemonNews, including a new Darby Daemon adventure.

5 of 101 comments (clear)

  1. What a legend... by acb · · Score: 3

    Not only did he write a C compiler, he's also dating Winona Ryder. The man is a living god.

  2. Solaris VM White Paper by Jubal+Kessler · · Score: 3

    I read up on the Solaris VM model a few days ago while trying to debug some Solaris boxen at work. It's an interesting read and covers the basic VM model and system diagnostic tools, including helpful detail of vmstat(1). Not as straightforward as Mr. Dillon's excellent FreeBSD VM article, but worth the look for comparison purposes.

    The link to the PDF file is the first one on this page; check out the others as well if you're interested in finding out about more Solaris internals:

    http://www.sun.com/sun-on-net/perfo rmance/



    ----
    Jack of all trades, master of none: http://whole.net/~pup/
  3. Re:Just an observation by raytracer · · Score: 5
    There's a reason for this, and it's pretty obvious - it's precisely because they're Open Source. If you want to learn how the internals work, you can go to the ultimate description - the source code.

    Don't get me wrong, though, higher level descriptions are good and neccessary. It's just that they're not essential when dealing with Open Source Operating Systems. The reason there are so many "Windows Internals" type books is because those systems are closed, and worse, those higher level descriptions are often the only ones you can get of the system.

    This comes perilously close to saying "we don't need documentation, that's what the code is for!" A truly dangerous path to stray down.

    The code is good at one thing: telling the machine what to do. It is often a pretty poor mechanism for documenting what you wanted it to do. It is also a poor mechanism for documenting what your concerns were, what you tried but found didn't work very well, what used to be implemented here, where your inspiration came from, etc... etc....

    Unfortunately, many projects (open source projects included, but of course not exclusively) suffer from a combination of snobbery (if you really knew what you were doing you'd read the code and figure it out) or worse yet, a lack of design itself (it just works okay). It's too easy to hide lack of design and poor design in this way.

    The FreeBSD VM article was exactly the kind of article that open source authors should be working toward. Document what you think. Document what you try. Document what the code does. There is more to programming than just knowing what C programs do.

    --

    There is much pleasure to be gained in useless knowledge.

  4. NetBSD virtual memory by acarlisle · · Score: 4

    For those interested, the UVM web page describes the UVM virtual memory system used in NetBSD.

    -AC

  5. Page Coloring by codealot · · Score: 3

    Interesting notes about page coloring... I didn't know FreeBSD had this capability.

    Linus has stated that he probably will never add page coloring to the Linux kernel. Apparently he doesn't believe it will benefit enough architectures to be worthwhile.

    On an Alpha 21164 many binaries run faster on Tru64 Unix than on Linux. Static linking rules out differences in the compilers or libraries. Page coloring (a feature of Tru64) is almost certainly the reason.

    At last I feel compelled to go try FreeBSD...