Re: [9fans] Virtual memory in BSD and Plan9

["John S. Dyson" <dyson@iquest.net>]

cross@math.psu.edu (Dan Cross) wrote in message news:<200110312021.PAA15416@augusta.math.psu.edu>...
> In article <3BE038E9.6AC0BD50@null.net> you write:
> >One big difference I've seen in past examples of paging systems
> >can be summarized as: page against everyone vs. page only against
> >oneself.  The latter is sometimes called the "working set" model.
> >The former tends to make the whole system unusable when a process
> >lets its address space get out of control, while the latter tends
> >to run other processes pretty much the same under such conditions.
>
> Forsyth wrote an interesting paper years back called something along
> the lines of, ``Sending Unix to the Fat Farm,''  wherein he details his
> experience replacing various parts of the SunOS 3 kernel in an effort
> to simplify the overall system.
>
> Of particular interest was his replacement of the whole-system paging
> scheme inherited from 4BSD with one based on the working set model.
> Apparantly, the system performed much more gracefully under load as a
> result, in addition to being far simpler and more maintainable.
>
> One of the things that bothers me about the Linux and BSD camps is that
> they don't learn from such experiences of the past, and instead forge
> ahead with the status quo that they've inherited.  For instance, the
> idea that Plan 9 would port one of the BSD paging subsystems is
> ridiculous for the same reason that the idea of porting the sockets
> subsystem is ridiculous; the system simply doesn't need it, it wouldn't
> mesh well with the overall architecture, and possibly better solutions
> exist in the literature.  In this specific case, the subtle nuances
> that Dyson describes in the FreeBSD paging code are precisely the sort
> of thing that Plan 9 does to great lengths to avoid.
>
Remember -- it was EXACTLY learning from the past that made the FreeBSD
VM outperform almost everything that exists to date (under load.)   The
old working set concepts are really not very good, because they work
alot like a 'command economy'.   Refer to the FreeBSD stats gathering,
plus the avoidance of resource depletion, plus the avoidance of long
queue lengths (maintains latency performance.)

Really, really -- there is alot to be said about learning from mistakes
in the past, and I holeheartedly agree.   However, the FreeBSD VM is
not just a follow-on to the MACH VM WRT it's behavior.   The incredible
thing about the FreeBSD VM is that it DOES do a good job of avoiding
the problems with the old concepts.

For alot of fun, just play with NT (a working set model VM), and FreeBSD,
and it will be pretty clear that FreeBSD tends to keep it's wits about
it.   There are some caveats in system configuration in order to maintain
performance under the grossest load conditions, and one is that multiple
heads makes a HUGE difference.   This is NOT because of bandwidth issues,
but due head contention.

John