Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mcnc!uvaarpa!virginia!uvacs!edison!toylnd!dca
From: dca@toylnd.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: The Next Generation
Message-ID: <187@toylnd.UUCP>
Date: Wed, 2-Dec-87 23:59:32 EST
Article-I.D.: toylnd.187
Posted: Wed Dec  2 23:59:32 1987
Date-Received: Wed, 9-Dec-87 20:58:21 EST
References: <2785@megaron.arizona.edu> <5294@ccicpg.UUCP> <468@ra.rice.edu> <475@ra.rice.edu>
Organization: Dave & Anne in Charlottesville, VA
Lines: 79

> Ok.  I'll be more specific.  Berkeley 4.x Unix is a poor example of a
> virtual memory implementation.  Do you want exmaples of what is better?
> How about VMS?  Forget the lousy user interface---I'm talking strictly
> virtual memory handling.  Does Unix use a working set model?  Does it make
> any attempt to prevent humongous Lisp and Prolog jobs from destroying
> everyone's performance?  Not in my experience.  But VMS does.  And what
> about swapping strategies?  Some would argue that you don't need to handle
> swapping separatly from paging.  I might be inclined to agree.  But that's
> beside the point.  BSD does swapping, but it allocates swap space using
> the "buddy block" system.  Can you say "massive fragmentation"?  I knew
> you could.
> 
It is to laugh.  I dare you to post this to unix-wizards, they would rip you
to shreds.
It is pretty easy given any paging system to find cases which will cause poor
performance.  What lies underneath the points made above is a difference in
philosophy.  You could argue that VMS's is superior I can and will argue
the Unix is superior.  By the way, VMS doesn't use the Working set model
either since the working set is an idealization which can't be arrived at
by static analysis or fixed allocation.  Certainly the working set for a
running process is frequently time variant.  VMS 'working sets' is a
statically allocated number of pages which must be available for a process
to run and a hard limit on the number of pages which the process is allowed
to use.  I'm not clear exactly how they come up with these numbers but
in my experience they are frequently not very good.

> When VMS gets memory constrained, it just gets slow, penalizing the
> larger proccesses.  But when Unix gets memory constrained, it gets
> unusable!  We have had horrible experiences here at Rice with just 10
> people trying to use the same Vax 750 running BSD:  the students are
> working on Modula II programs, they all use Gosling's emacs to edit, and
> two people cannot reliably compile at the same time.  Even with 8
> megabytes (the most memory you can put in a 750).
> 
How good does VMS run on a 750 with a similar number of people doing similar
things.  Give me a break!  I may not have the I/O bandwidth but I've got
more CPU power on the 3b1 I'm typing on.

VMS is designed by bean counters for bean counters.  Unix is designed by
programmers for programmers.  Programmers are interested in maximum
utilization of the resources of the machine.  If there is one job running on
the machine then they want it all if there is 100 jobs running on the machine
they want their piece of it.  VMS is interested in stuffing as many people on
a machine as possible and carefully limiting their use of resources.
BSD uses a global page scheme where pages are allocated on a LRU
basis.  If you are the only process on the machine and you need a large amount
of memory then you can efficiently utilize the entire machine.  BSD will
resort to swapping if paging performance degrades beyond a certain point.
If you have to share the machine then performance will degrade but the memory of
the machine will still be close to maximally utilized.  VMS uses a local
(yuck!) page scheme where pages are allocated on a FIFO basis (double yuck!).
Your so called 'working set' must be available for your process to run and
pages in your local set are not available for reuse on a global basis
(even if you don't need them anymore).  The fact is, a process that hogs
memory on a BSD system probably wouldn't even run reasonably on a VMS system
(unless of course it was given a hoggy working set size).  Further evidence
of this bean counter vs. programmer conflict is available in the scheduling
priorities of a VMS system.  VMS priorities divide processes into groups of
'those that get time' and 'those that get no time' unless there is some
time which the 'those that get time' are not using.  BSD divides processes
into groups of 'those that get more time' and 'those that get less time'.
Process niceing can be used on BSD processes to get performance similar to
that of a VMS system without causing the negative effects of the fixed
resource allocation strategies in VMS.  It is ludicrous to be on a unloaded
machine with a large process and be paging through a keyhole.  On the VMS
systems that I used there were large portions of the physical memory which had
never seen a process.
>
> Do you think that all research work in
> virtual memory systems stopped when BSD came out?  Come on!  It only makes
> sense that something better exists today, simply because of progress in
> the field.
> 
Certainly BSD vm isn't the be all and end all of virtual memory systems.
Holding up VMS as superior, however, is a bit odd.  Hey, DEC didn't even
put a reference bit on the VAX paging system because VMS uses FIFO and
didn't need it, talk about neanderthal.

David Albrecht