Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!beta!hc!ames!amdcad!rpw3 From: rpw3@amdcad.UUCP Newsgroups: comp.arch Subject: Re: VM, Paging, Demand Paging Message-ID: <18512@amdcad.AMD.COM> Date: Wed, 31-Dec-69 18:59:59 EDT Article-I.D.: amdcad.18512 Posted: Wed Dec 31 18:59:59 1969 Date-Received: Sun, 4-Oct-87 01:42:13 EDT References: <8490@think.UUCP> <1745@ncr-sd.SanDiego.NCR.COM> <819@sugar.UUCP> <1755@ncr-sd.SanDiego.NCR.COM> <4780@ncoast.UUCP> <736@winchester.UUCP> Reply-To: rpw3@amdcad.UUCP () Organization: [Consultant] San Mateo, CA Lines: 50 Summary: Simple non-demand "paging" can avoid shuffling (of either kind) The one thing that "paging" buys you on a PDP-11 is some decrease in internal fragmentation of memory. That is, if you allocate memory in 8k "pages", and allow "pages" of the user's job to go in any free "page", you can often avoid "shuffling" a job around in memory merely to get contiguous memory to swap in another job. Much of the "swapping" a PDP-11 Unix did was actually shuffling, because since the DMA disk rate was far higher than the CPU memory-to-memory copy rate, it was cheaper (in total overhead) to swap out/in than to shuffle with the CPU. (At Fortune Systems, we had very slow disks on a 68000 system, so the reverse was true. Telling the [Version 7] swapper about that also meant that you could fork() without swapping, since in V7 the forced-swap-on-fork was really a shuffle hack. Yes, the Fortune had PDP-11 style base/limit segmentation, with only 4 segments.) Even with the above kind of "paging", you would still want to "swap" the entire job in and out on a PDP-11. Another way of saying it, "page", but make the working set equal to the whole process so a job never gets "page faults". <> This has been used on other systems as well. When DEC first introduced the KI-10 (a kind of PDP-10), which has a paging MMU unlike the base/limit MMU of the KA-10, they were concerned that they didn't know yet how to do paging well without impacting performance, so they simply used the pager to emulate the base/limit box. The next few releases didn't do demand paging in the O/S, but *did* use the MMU in paging mode to avoid shuffling, which was a major overhead in the KA-10 since PDP-10 jobs are often of wildly different sizes. This resulted in a noticable performance improvement over the shuffling version, so much so that some users turned off shuffling in their KA-10's, forcing them to do PDP-11-Unix-style "shuffling" via the swapper! It ran a lot better, in large timesharing systems with a bunch of small jobs. (It was not unusual in those days to see 50+ users on a poor KA-10!) [If you turned off shuffling. the KA-10 swapper could deadlock if you allowed users to run a job bigger than 1/2 of real memory, so if you wanted to turn off shuffling, you had to limit the size of the job. The kernel had memory quotas, so it was a simple config setting.] <> Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403