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