hutch@sdcsvax.UUCP (Jim Hutchison) (09/02/86)
<>
As memory prices drop and other economic things come to pass,
suddenly we have people asking for big fast memory. Maybe RAM,
maybe SUPER disk, maybe super-cooled core. Whatever it is going
to be, paging will still go on. (Atleast thats a best guess, but
I digress)
Decoding an address is a look up. Simple cascades will not cut it in
the GB or TB range (you laughed at the first guy who said Gig, how
about Tera! :-). Log(n) is nice, but seconds (plural) is not all that
fun for finding a page, even if you go for 8,16 legged trees (base
8,16).
Perhaps having clusters of pages, grouping allocations. This would
help for 2000+ user systems (giving everyone their own cluster or even
one per process), but would fail miserably for the 2GB data base.
Each process having a page translation table, and a VM system which
could grok processes or would only look in one place (via another
translation table perhaps).
It keeps coming back to that translation.
Well how about a mix. A reasonable N MB of virtual memory paged
by whatever scheme you have in hand, and N TB of physical memory
mapped way out somewhere. You could have the real near and the
virtual far if you wanted. Probably easier for faulting and all
that noise. You still have a VM machine, its just that the VM
is way out there where you may not have to use it.
Yes, this rapes the virtual memory environment. Segmentation comes
to mind as something to put on top of the two for protection and
address monkeying (every process gets to have its space start at 0
or whatever makes life easy).
Dabble, yes, flames if you must, please be informative with them.
--
Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch
ARPA: hutch@sdcsvax.ucsd.edu
"Disclaim, disclaim, off to post I go."jeff@gatech.CSNET (Jeff Lee) (09/02/86)
> Log(n) is nice, but seconds (plural) is not all that >fun for finding a page, even if you go for 8,16 legged trees (base >8,16). As the memories get bigger, all of a sudden random replacement starts to look not so bad.... :-) -- Jeff Lee CSNet: Jeff @ GATech ARPA: Jeff%GATech.CSNet @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!jeff
jin@hropus.UUCP (Jerry Natowitz) (09/02/86)
[Time required for virtual memory mapping in huge memory systems] How about increasing the page size proportionally to the memory size. If you got gigabytes to burn what's wrong with a 1 meg page? -- Jerry Natowitz (HASA - A division) Bell Labs HR 2A-214 201-615-5178 (no CORNET) ihnp4!houxm!hropus!jin or ihnp4!opus!jin Isn't it interesting how the beautiful little red flower in the forest becomes so ugly when you discover it's a candy wrapper.
dwc@hou2b.UUCP (D.CHEN) (09/03/86)
>[Time required for virtual memory mapping in huge memory systems] >How about increasing the page size proportionally to the memory >size. If you got gigabytes to burn what's wrong with a 1 meg page? one thing that has to be considered then is disk transfer rate. while there is not too much difference in transfer times for .5K and 4K pages, a 1M page will take a substantial amount of time to load. without thinking too much, the problem looks like it would be solved with a corresponding growth in address translation buffer size. it locality of reference still applies in those applications using large address spaces, then the growth in the address translation buffer need not even be linear in address space size. danny chen ihnp4!hou2b!dwc by the way, i don't even think that page table management scheme need be quadratic or linear with page table size. i can think of at least a couple of schemes that are more or less constant. it is interesting though that all the popular paging strategies taught in school do exhibit poor behavior when used with large address spaces and/or large memories.
peters@cubsvax.UUCP (Peter S. Shenkin) (09/03/86)
If big main memory gets REALLY cheap, maybe we won't need virtual memory any
more. Most jobs could just grab a partition of core and live there till they
die. Another partition could be used to run a virtual machine in for bigger
jobs, which perhaps could be run as batch jobs in off-hours more profitably...
Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027
{philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPAjin@hropus.UUCP (Jerry Natowitz) (09/04/86)
> If big main memory gets REALLY cheap, maybe we won't need virtual memory any > more. Most jobs could just grab a partition of core and live there till they > die. Another partition could be used to run a virtual machine in for bigger > jobs, which perhaps could be run as batch jobs in off-hours more profitably... > > Peter S. Shenkin Columbia Univ. Biology Dept., NY, NY 10027 > {philabs,rna}!cubsvax!peters cubsvax!peters@columbia.ARPA I think my definition of virtual memory might be out of synch with others. Cheap large memories mean that we would be able to do away with demand paging. We would still need address translation unless every process was written in position independent code (no address constants at assembly/compile time etc.) Does virtual memory imply demand paging or just address translation? -- Jerry Natowitz (HASA - A division) Bell Labs HR 2A-214 201-615-5178 (no CORNET) ihnp4!houxm!hropus!jin or ihnp4!opus!jin Isn't it interesting how the beautiful little red flower in the forest becomes so ugly when you discover it's a candy wrapper.
jlg@lanl.ARPA (Jim Giles) (09/06/86)
In article <826@hou2b.UUCP> dwc@hou2b.UUCP (D.CHEN) writes: >... >one thing that has to be considered then is disk transfer rate. >while there is not too much difference in transfer times for .5K >and 4K pages, a 1M page will take a substantial amount of time to >load. >... Disk is actually slower than that. The seek time (for any size transfer) is generally comparable to the time-slice in your environment (at least on those machines which presently have big memories - Cray, Cyber 205, etc). Since your program loses its time-slice on every page fault anyway, the page size might as well be large. But, then again, I'm not really in favor of virtual memory on large machines anyway. J. Giles Los Alamos
henry@utzoo.UUCP (Henry Spencer) (09/07/86)
> If big main memory gets REALLY cheap, maybe we won't need virtual memory any > more... The odds are that the demand for address space will continue to grow faster than the memory sizes. In any case, people who argue on this basis miss an important point: virtual memory is not a substitute for real memory. To quote one of my friends over at HCR: "real memory for real performance". The point of virtual memory is not that it's as useful as real memory -- it is useful in direct proportion to the extent to which it is backed by real memory -- but that it turns a hard limit into a soft limit. If you do not have virtual memory, then a job which doesn't quite fit is unrunnable. If you do not have virtual memory, and your main memory is slightly over- committed, then much more drastic measures like swapping will have to be used, with much more serious impact on performance. Virtual memory does increase the effective size of memory for many applications (big number- crunching things are often an exception, which is why virtual memory is not popular in that community; it doesn't do them much good), but it also makes performance degrade gradually, instead of sharply and disastrously, when memory is slightly short. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (09/07/86)
> ... Does virtual memory imply demand paging or just address translation?
"Virtual memory", strictly speaking, refers to memory that acts like it's
always there but sometimes isn't. That is, demand paging or some analogous
scheme (paging is not the only memory-management technique possible, and
demand paging is not the only page-fetching policy possible). Address
translation, by itself, is not virtual memory.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henryken@argus.UUCP (Kenneth Ng) (09/08/86)
In article <654@hropus.UUCP>, jin@hropus.UUCP (Jerry Natowitz) writes: > > I think my definition of virtual memory might be out of synch with > others. Cheap large memories mean that we would be able to do away > with demand paging. Memory may be becoming cheaper, but the addressing range of processors is becoming bigger. The IBM XA (I think) is supposed to support 31 bit addressing, and the Intel 386 is supposed to address 48 bit addressing! We still have several generations to go, unless we settle for very BIG memory boards. > Jerry Natowitz (HASA - A division) > Bell Labs HR 2A-214 > 201-615-5178 (no CORNET) > ihnp4!houxm!hropus!jin > or ihnp4!opus!jin -- Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 uucp(for a while) ihnp4!allegra!bellcore!argus!ken *** WARNING: NOT ken@bellcore.uucp *** !psuvax1!cmcl2!ciap!andromeda!argus!ken bitnet(prefered) ken@orion.bitnet --- Please resend any mail between 10 Aug and 16 Aug: --- the mailer broke and we had billions and billions of --- bits scattered on the floor.
ed@mtxinu.UUCP (Ed Gould) (09/08/86)
Henry Spencer: >"Virtual memory", strictly speaking, refers to memory that acts like it's >always there but sometimes isn't. I would quibble slightly. To me, virtual memory refers to a memory space that is different than the physical memory of the machine. A PDP-11 has a virtual memory space of 2^16 bytes, or perhaps 2*2^16 bytes. But some models of the machine have a physical memory space of nearly 2^22 bytes. This is not what most people - including me - usually mean when casually talking about virtual memory. Then, it does refer to a virtual space that is larger than the available physical space (available either because the remainder is allocated to other uses, or not physically present), and is managed by some technique like demand paging that allows partly- resident processes to execute. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
greg@ncr-sd.UUCP (Greg Noel) (09/08/86)
In article <7092@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> ... Does virtual memory imply demand paging or just address translation? > >"Virtual memory", strictly speaking, refers to memory that acts like it's >always there but sometimes isn't. That is, demand paging or some analogous >scheme (paging is not the only memory-management technique possible, and >demand paging is not the only page-fetching policy possible). Address >translation, by itself, is not virtual memory. Hmmmmm..... I think I want to take issue with this. Although what Henry says is valid, his point is too narrow. Two immediate counter-examples are the SDS-940 (later the XDS-940) and the PDP-11, both of which are virtual- memory machines, and yet essentially just only do address translation. (I know, I know, later versions of the PDP-11 can restart instructions; the point remains.) Perhaps more to the point would be to say that the memory image seen by the program is independent of the real memory provided by the machine. That is, the operating system can assign arbitrary portions of real memory to the program and this mapping can change over time. In this context, some amusing definitions: Real: You've got it, and you know you've got it. Transparent: You've got it, but you don't know you've got it. Virtual: You don't have it, but you don't know it. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
kendalla@blast.gwd.tek.com (Kendall Auel) (09/09/86)
In article <1162@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >In article <7092@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >>> ... Does virtual memory imply demand paging or just address translation? >> ... Address translation, by itself, is not virtual memory. > ... Perhaps more to the point would be to say that the memory image seen by > the program is independent of the real memory provided by the machine. I had always thought that virtual memory meant address translation only, and that a memory hierarchy (cache, RAM, disk, tape, ...) did not necessarily exist in a virtual memory system. When I looked it up, however, my textbooks speak of virtual memory as a way to map backing store into the address space of the processor: "Virtual memory is a technique which allows the execution of processes that may not be completely in memory. The main visible advantage of this scheme is that user programs can be larger than physical memory." - Peterson & Silberschatz; _Operating_Systems_Concepts_ "Virtual memory provides the user with a memory that can be larger than physical Mp. The virtual memory system handles overlays in a user-transparent manner by deferring the binding between user and physical addresses until instruction execution time." - Siewiorek, Bell, Newell; _Computer_Structures:_Principles_and_ Examples_ I got two points from this reading. 1) Virtual memory *technically* implies only address translation, and 2) The main advantage to using virtual memory is to extend physical memory via a backing store (disk, drum, ...). Thus, the concept of virtual memory for all intents and purposes implies swapping memory to and from a disk, as well as address translation. Kendall Auel Tektronix, Inc.
henry@utzoo.UUCP (Henry Spencer) (09/11/86)
> >"Virtual memory", strictly speaking, refers to memory that acts like it's > >always there but sometimes isn't. That is, demand paging or some analogous > >scheme ... Address translation, by itself, is not virtual memory. > > Hmmmmm..... I think I want to take issue with this. Although what Henry > says is valid, his point is too narrow. Two immediate counter-examples are > the SDS-940 (later the XDS-940) and the PDP-11, both of which are virtual- > memory machines, and yet essentially just only do address translation... I assure you that the PDP-11 is *not* considered a virtual-memory machine, not by DEC, not by anyone who knows the machine and knows what the words mean. (Well, you can sort of do virtual memory on the 11, but none of the popular operating systems bother.) Why do you think the Berkeley Unixes also go by the name "VMUNIX"? The "VM" part stands for "virtual memory", which earlier Unixes -- on the 11, and on the VAX with address translation but no demand paging -- were not. > Perhaps more to the point would be to say that the memory image seen by the > program is independent of the real memory provided by the machine... This would be a reasonable meaning for the term "virtual memory", but it is not the standard one. Check any good operating-systems textbook. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (09/11/86)
> >"Virtual memory", strictly speaking, refers to memory that acts like it's > >always there but sometimes isn't. > > I would quibble slightly. To me, virtual memory refers to a memory space > that is different than the physical memory of the machine... It would be reasonable to use "virtual memory" to denote that concept, but that is not in fact the concept that it *does* denote. In the same way, "RAM" stands for "random-access memory", which one would think should include things like EPROMs... but in fact "RAM" is now an idiom whose meaning is not identical to the literal meaning of the words it is derived from. So with "virtual memory". > This is not what most people - including me - usually mean when casually > talking about virtual memory... That's because your casual talk uses the phrase in its correct, idiomatic, meaning, rather than attempting to read it literally and impute to it a meaning that it never had. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (09/11/86)
> I had always thought that virtual memory meant address translation only, and > that a memory hierarchy (cache, RAM, disk, tape, ...) did not necessarily > exist in a virtual memory system. When I looked it up, however, my textbooks > speak of virtual memory as a way to map backing store into the address space > of the processor... > > I got two points from this reading. 1) Virtual memory *technically* implies > only address translation, and 2) The main advantage to using virtual memory > is to extend physical memory via a backing store (disk, drum, ...)... Can you explain how you arrived at those points from the evidence presented? Your textbooks clearly state that virtual memory IS the extension of physical memory via a backing store. They are correct; the phrase first came into use to describe exactly that concept. It's true that its literal meaning is a bit different, but that's true of any idiomatic term. The literal meaning of "computer" is "something which computes, i.e. does arithmetic". This then includes a human with a slide rule (in fact, fifty years ago "computer" was the job title for a desk-calculator operator) and probably does not include a database machine (which does little or no arithmetic). But that's not the meaning normally understood for "computer". -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
greg@ncr-sd.UUCP (Greg Noel) (09/12/86)
In article <7621@tekecs.UUCP> kendalla@blast.UUCP (Kendall Auel) writes: >In article <1162@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >> ... Perhaps more to the point would be to say that the memory image seen by >> the program is independent of the real memory provided by the machine. >I had always thought that virtual memory meant address translation only, and >that a memory hierarchy (cache, RAM, disk, tape, ...) did not necessarily >exist in a virtual memory system. This is true. In fact, I have seen a design for an embedded computer with no backing store that used virtual memory to improve its real memory utilization. The tasks ran in a largish virtual space and the unallocated memory simply wasn't mapped. The memory allocator had some heuristics to minimize the number of pages occupied and didn't hesitate to leave large sections of the virtual memory unused and unmapped. Typically, fragmentation causes you to run out of space when there is as much as one-third of the memory still available (see Knuth, Vol. I for details); with this scheme, we could depend upon functioning with over 90% utilization, and often over 95% -- it was like adding half again as much memory...... I wish my Amiga used this trick; it's irritating to run out of memory when the system claims that it still has 220K free....... >When I looked it up, however, my textbooks >speak of virtual memory as a way to map backing store into the address space >of the processor: [.... quotes deleted .....] > >I got two points from this reading. 1) Virtual memory *technically* implies >only address translation, and 2) The main advantage to using virtual memory >is to extend physical memory via a backing store (disk, drum, ...). Thus, the >concept of virtual memory for all intents and purposes implies swapping memory >to and from a disk, as well as address translation. An accurate assessment, I think. Although there are reasons to separate the two concepts, they work so well together that it is hard to consider them independantly. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
elg@usl.UUCP (Eric Lee Green) (09/13/86)
<munch>
Re: What is virtual memory?:
One of the big programmer benefits of modern operating systems is that
they give each user his own "virtual machine" to run his programs on,
that is, to some extent, each program thinks it has the machine all to
itself, and doesn't have to worry about what other processes are
doing. Virtual memory is basicaly the "memory" of this virtual
machine. For example, in the PDP-11 example -- each process thought it
was running on a 64K machine. While on this Vax, each program thinks
it is running on a 4 gigabyte machine. While on the 80286, the
machine's virtual memory consists of the fact that it makes it look to
each process as if it can access 64,000 64k segments. Note that paging
is not the only way to do things -- the 80286 has no paging and yet
its memory management scheme certainly qualifies as "virtual memory",
while the PDP-11 also swapped out its 64K segments when something else
needed to be run. But, basically, the point is:
a) Each process is given its own virtual machine, which has a constant
amount of memory, so that
b) programs can be designed for that virtual amount of memory, and do
not have to contain a bunch of special clauses for when the actual
physical amount of memory changes sometime in the future.
The grossest abuse of course is VM, where not only do they make it
look like the process is running on its own processor, but has its own
directly addressible i/o devices also. Talk about taking things to
extremes!
Eric
--
Eric Green {akgua,ut-sally}!usl!elg
(Snail Mail P.O. Box 92191, Lafayette, LA 70509)
-- Tengo lo mismo que doy y solo sirve al presente. aglew@ccvaxa.UUCP (09/14/86)
... > Henry Spencer describes virtual memory as a technique for making
... > the hard limit of physical memory into a soft limit.
Right. Consider these hypothetical graphs (I hope these come out
- I'm not using tabs):
Strictly physical memory system:
The cost of doing overlays
_/ (Chunked according to interconnectivity
_/ of program and data, and accuracy of
/ predictions)
_____________/ Physical Memory Speed
Size of Program/Data--->
The vertical axis might be program speed or SW development cost.
|
Virtual Memory System _____________|
_____________/
_______________/
(penalty for virtual memory)
___________________________________________
^ ^
| Physical memory limit | Virtual memory limit
For SW development, the penalty for virtual memory is nearly zero
(certainly zero for applications, but nonzero for OS, since somebody has
to write the memory management software). For execution, however, the
virtual memory penalty is appreciable - it may not slow you down, but it
will certainly take hardware and floorspace that you might have devoted
to something else. The question is, where do most of your applications lie
- below the physical memory boundary, or above? - and which ones cause people
to buy your system?
Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vmsdwc@hou2b.UUCP (D.CHEN) (09/16/86)
> Another consideration, is that on at least some virtual > memory systems I've worked with, the the system transfers > the program over to some sort of paging file, before it > starts, which means that you end up reading the whole > program in anyway, and writing it out to boot. Does anyone > know of a virtual memory system that doesn't work this > way? i think that alot of the minicomputer based operating systems don't work this way. it has something to do with the size of the paging area. many systems are not configured to have enough swap or paging space to hold all the programs that may run at once. also, in order to recoup the overhead in doing the read and write of the program file (in order to put it contiguously on the paging file), the program would have to run long enough to make it worthwhile. at least in the unix environment, this is generally not the case (you know, build applications using small tools and all that). one other aspect that i think is interesting is this: those systems that attempt to write everything to the paging file first are attempting to reduce the work to do reads (or page ins...assuming that program behavior allows them to take advantage of contiguity). those systems that do not guarantee contiguity on the paging file are attempting to reduce work for writes (page outs). so the choice depends on: 1) how much more often reads are done than writes 2) how long process run and memory contention > I'm no big fan of virtual memory. It made sense back in the > days of timesharing systems with expensive core memories, > but now with cheap semiconductor memory RAM disks and big > disk caches make more sense. virtual memory isn't that bad. there are several advantages that can be useful when there just isn't enough physical memory. if there is, and if the virtual memory scheme is flexible enough, about all you pay is the cost of page and segment table address translation. aside from some semantic differences between files and memory address space, a virtual memory scheme can provide "large disk caches" if there is the ability to map files into address spaces. in fact, in unix, alot of the structure of the buffer cache and memory management would be duplicated if we had memory mapped files. and still being a believer in a weak form of locality of reference, i feel that the ram used in a ramdisk is better used in main memory where the o.s. has an opportunity to control its allocation for higher utilization (there are other factors of course). danny chen ihnp4!hou2b!dwc
greg@ncr-sd.UUCP (Greg Noel) (09/24/86)
In article <7110@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >I assure you that the PDP-11 is *not* considered a virtual-memory machine, >not by DEC, not by anyone who knows the machine and knows what the words >mean. That's an awfully snippy comment. Just because the virtual space is smaller than the physical doesn't mean that it isn't a virtual machine. >Why do you think the Berkeley Unixes >also go by the name "VMUNIX"? The "VM" part stands for "virtual memory", >which earlier Unixes -- on the 11, and on the VAX with address translation >but no demand paging -- were not. "You can call a tail a leg, but that doesn't make it one." (Actually, that's not quite correct, either. Indeed, "VMUNIX" is a virtual memory operating system -- but then, so were the earlier ones.) I will agree that an extremely strong motivation for virtual memory is so that you are not required to have all of your program residing in physical memory. I will even agree that most virtual memory systems use some form of paging (or whatnot) for memory management -- but that doesn't mean that the concepts are the same, or that virtual memory mandates paging. There are other, perfectly valid reasons to have virtual memory. I think the problem here is one of age. Henry is probably too young to have heard the terms used correctly and is using the (usually very reasonable) assumption that if A and B always occur together, then A implies B. On the other hand, I worked on the Project Genie time-sharing system (one of the two original ARPA-funded time-sharing projects; the other was Project Multics), so I can claim some degree of expertise on the topic. The fundamental concept of virtual memory is that a large name space (the virtual memory) can be partially mapped to a smaller name space (the physical memory) with the remainder of the space unmapped. Uttering a name that is not mapped causes some sort of an exception mechanism, but the semantics of that exception are not part of the virtual memory model. Admittedly, the concept is not terribly interesting unless you postulate some exception semantics, but paging is just one potential set of exception semantics, not the \only/ one. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
henry@utzoo.UUCP (Henry Spencer) (10/06/86)
> "You can call a tail a leg, but that doesn't make it one." > ... > I think the problem here is one of age. Henry is probably too young to have > heard the terms used correctly and is using the (usually very reasonable) > assumption that if A and B always occur together, then A implies B... This is an amusing juxtaposition. Greg, please see any good computer-science dictionary and encyclopedia for the *modern* meaning of "virtual memory". What it was considered to mean twenty years ago is not relevant; that's a very long time ago in this field. The meanings of words are defined by how they are used, not by how they used to be used. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
phil@amdcad.UUCP (Phil Ngai) (10/08/86)
In article <1181@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >In article <7110@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > >>I assure you that the PDP-11 is *not* considered a virtual-memory machine, >>not by DEC, not by anyone who knows the machine and knows what the words >>mean. > >That's an awfully snippy comment. Just because the virtual space is smaller >than the physical doesn't mean that it isn't a virtual machine. I think there is a confusion here on Greg's part between virtual address space and virtual memory. No one who has studied PDP-11 memory management will deny that some PDP-11s support virtual addressing. In fact, VAX stands for Virtual Address eXtension, implying that the virtual address concept is not new to DEC's product line. However, this is not the same as virtual memory, as Greg seems to think. The VAX architecture handbook goes on to say "a virtual memory system is used to provide a large address space while allowing programs to run on hardware configurations that actually have smaller memory sizes." >>Why do you think the Berkeley Unixes >>also go by the name "VMUNIX"? The "VM" part stands for "virtual memory", >>which earlier Unixes -- on the 11, and on the VAX with address translation >>but no demand paging -- were not. > >"You can call a tail a leg, but that doesn't make it one." > >(Actually, that's not quite correct, either. Indeed, "VMUNIX" is a virtual >memory operating system -- but then, so were the earlier ones.) I don't see any basis at all for this claim that the earlier forms of Unix were virtual memory operating systems. Virtual address space, yes, for memory management is very important to a multi-tasking operating system. But virtual memory, no. -- DIP stands for DECnet-DOS Installation Procedure. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
edsxdev0@ihlpm.UUCP (Bruzzini) (10/10/86)
> This is an amusing juxtaposition. Greg, please see any good computer-science > dictionary and encyclopedia for the *modern* meaning of "virtual memory". > Henry Spencer @ U of Toronto Zoology From my dictionary of computer terms: virtual memory: The mapping of a program address into a physical memory address, usually done by hardware. paging: The operation of moving pages of information to and from secondary storage Daryl Monge NET: ihnp4!ihelp!dlm AT&T CIS: 72717,65 Bell Labs Naperville, Ill.
jlg@lanl.ARPA (Jim Giles) (10/12/86)
In article <7190@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >... >What it was considered to mean twenty years ago is not relevant; that's a >very long time ago in this field. The meanings of words are defined by how >they are used, not by how they used to be used. Quite so. I remember when 'hacker' was a derogatory term. I still use it that way, but no one else seems to. J. Giles Los Alamos
tan@cae780.UUCP (10/14/86)
In article <842@ihlpm.UUCP>, edsxdev0@ihlpm.UUCP (Bruzzini) writes: > > From my dictionary of computer terms: > > virtual memory: The mapping of a program address into a physical memory > address, usually done by hardware. > > > Daryl Monge NET: ihnp4!ihelp!dlm > AT&T CIS: 72717,65 > Bell Labs > Naperville, Ill. I don't know which computer dictionary you are using. To me, virtual memory is a logical memory. The address space of virtaul memory is, usually, >> that of physical one. The mapping is just a mechanism to convert the logical memory space to the physical one (in run time). I believe you need a better dictiionary.
jeff@voder.UUCP (Jeff Gilliam) (10/15/86)
It seems to me that the only thing that this discussion has proved is
that "virtual memory" is an ill-defined term. Let us accept that fact
and get on to other topics.
--
Jeff Gilliam {ucbvax,pyramid,nsc}!voder!jeff