rpw3@amdcad.UUCP (01/01/70)
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".
<<computing_trivia ON>>
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.]
<<computing_trivia OFF>>
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 94403dhesi@bsu-cs.UUCP (Rahul Dhesi) (01/01/70)
In article <15250@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >The fundamental concept of VIRTUAL MEMORY is to allow the system to >appear to have more physical memory than there is (by paging/swapping, >whatever), hence the VIRTUAL. This is certainly the most common meaning. Unfortunately, the term "virtual memory" is often taken to mean different things by different people in different contexts. Consider these usages: 1. Address seen by CPU is not identical to address sent to memory. (E.g. any kind of relocation register addressing, as in DECsystem 10, or base register addressing as in IBM 360 or Intel 8086.) 2. Address space of process may be larger than amount of physical memory available. (E.g. demand paging or demand segmentation or a combination thereof, as in VAX-11/780.) 3. Memory is broken up into pieces and each piece is addressed separately and a contiguous address space may be simulated even though these pieces are scattered all over physical memory. (E.g. paged system without necessarily being demand-paged; can't think of any example machines but they must exist.) 4. Data structures may spill over from main memory to mass storage, and are moved in and out as needed by software. No special hardware is needed. (E.g. virtual arrays as in DEC BASIC on PDP-11 systems; possibly Pick operating system data structures on any machine.) 5. Data blocks are moved between main memory and disk as needed, with the help of hardware that causes a trap when a block that is not in main memory is accessed. (E.g. VAX again.) Many of these definitions overlap, especially 2, 3, and 5. I'm sure you can come up with other examples of usage. I've seen the term "virtual memory" used for all the above. So I suggest using more specific terms such as "swapping" or "base register addressing" or "demand paging" etc. whenever possible, just to avoid confusion. Thus people can rightfully claim that the 80286 CPU supports "virtual memory", but our response to that need be no more than a barely- suppressed yawn. But if they claim that the 80286 CPU supports "demand paging" you can nail them for it. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
ron@topaz.rutgers.edu (Ron Natalie) (10/02/87)
The fundamental concept of VIRTUAL MEMORY is to allow the system to appear to have more physical memory than there is (by paging/swapping, whatever), hence the VIRTUAL. It ain't virtual unless it isn't all there. -Ron
dwc@homxc.UUCP (10/03/87)
> If programs are relatively small [64K I + 64K D max] > and if pages are relatively large (compared to size) [8K], > then programs are likely to touch every or almost every page very quickly. > In this case, you get better disk performance, and have simpler, > denser kernel data structures, by swapping instead of paging. > I.e., if working set = size of program, you might as well swap. > > Note that many systems have performance domains where it is better > to swap either entire processes, or at least, their working sets, > in or out, rather than doing it piecemeal. Big IBM systems do this, for example. because of the nature of disks (i.e. latency plus rotational delay dominates), and because of large, fast memories, it will almost always pay to swap working sets. however, i believe that it also doesn't pay to do the swap i/o in units that are larger than what can be accommodated in a single physical i/o. for instance, there is often a track size limit on the size of an i/o transfer. the system would have to break up larger jobs into multiple jobs anyway. in this case, it pays to deal with the working set in these units instead of the page sized units for both swapping in AND swapping out. there is yet another "degree of freedom" which i am examining: preallocation of memory to reduce memory contention WITHOUT committing to doing any i/o. i hope to get a paper out of this, so keep your eyes open. danny chen ihnp4!homxc!dwc
dwc@homxc.UUCP (10/03/87)
In article <15250@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: > The fundamental concept of VIRTUAL MEMORY is to allow the system to > appear to have more physical memory than there is (by paging/swapping, > whatever), hence the VIRTUAL. > > It ain't virtual unless it isn't all there. > i guess it all depends on where you went to school and which text books you read. i had always been taught that virtual memory IMPLIED that there existed a MAPPING between virtual memory and physical memory that was not just one to one (and onto?). that is base register schemes also correspond to virtual memory. paging is just another example of this. demand paging ALLOWS for large address spaces but you can have paging hardware without demand paging (e.g. pre UNIX System V release ~2) and still run a virtual memory system. remember that this was still a win because it prevented fragmentation of memory even though physical memory was fragmented. danny chen ihnp4!homxc!dwc
aglew@ccvaxa.UUCP (10/07/87)
Transparent == "It's there, but it doesn't seem to be". Virtual == "It isn't there, but it seems to be".
spock@uop.UUCP (T R R L) (10/10/87)
In article <28200053@ccvaxa>, aglew@ccvaxa.UUCP writes: > > Transparent == "It's there, but it doesn't seem to be". > > Virtual == "It isn't there, but it seems to be". > Question == are these the only two or are there other combinations?
john@geac.UUCP (10/19/87)
In article <15250@topaz.rutgers.edu>, (Ron Natalie) writes: > The fundamental concept of VIRTUAL MEMORY is to allow the system to > appear to have more physical memory than there is (by paging/swapping, > whatever), hence the VIRTUAL. > > It ain't virtual unless it isn't all there. This reminds me of a quaint description of virtual memory, comparing it to real memory: "Computer memory is like sexual orgasm: It's much better when it's real than when it's faked." ;-) -john- -- John Henshaw, (mnetor, yetti, utgpu !geac!john) Geac Computers Ltd. "...and bring along a major credit card Markham, Ontario, Canada, eh? and a piece of ID..."