kannan@ut-emx.UUCP (Natarajan Shanmugh) (10/08/88)
Followup-To:
Distribution:
Organization: UTexas Computation Center, Austin, Texas
Keywords: Virtual Memory
I read an article in UNIX World comparing system V and AIX. It clearly stated that System V did not have VM(Virtual Memory concept). Can someone clear the following doubts for me through e-mail to nataraj@happy.cc.utexas.edu
(1) If there is no VM, how does the operating system, bring the programs from secondary storage to main for execution.(System V )
(2) How does MS-Dos solve the above problem?
(3) I have comments like Unix needs at least 4M of main memory?
Is it for all the daemons to run?
Thank you
nataraj@happy.cc.utexas.educlarke@acheron.UUCP (Ed Clarke) (10/10/88)
From article <6693@ut-emx.UUCP>, by kannan@ut-emx.UUCP (Natarajan Shanmugh): > Followup-To: > Distribution: > Organization: UTexas Computation Center, Austin, Texas > Keywords: Virtual Memory > I read an article in UNIX World comparing system V and AIX. It clearly stated that System V did not have VM(Virtual Memory concept). Can someone clear the following doubts for me through e-mail to nataraj@happy.cc.utexas.edu > (1) If there is no VM, how does the operating system, bring the programs from secondary storage to main for execution.(System V ) > (2) How does MS-Dos solve the above problem? > (3) I have comments like Unix needs at least 4M of main memory? 1. That's Virtual Machine not Virtual Memory. AIX uses VRM which is a sort of low level idealized machine that comes between AIX and the true hardware. It complicates life quite a bit when you want to add support for non standard devices. I think it's supposed to disapear in the future. 2. MS-Dos has neither. It's a program loader that runs in 8086/8088 mode (< 1 Meg). Yeah, it'll run on 80286/80386 machines, but it doesn't take advantage of any of the extended features. 3.) Unix always needs one more meg than you have installed, either main memory or secondary storage but usually both. ;-) -- Ed Clarke uunet!bywater!acheron!clarke
heiby@mcdchg.UUCP (Ron Heiby) (10/10/88)
kannan@emx.UUCP or nataraj@happy.cc.utexas.edu writes: > I read an article in UNIX World comparing system V and AIX. It clearly > stated that System V did not have VM(Virtual Memory concept). Well, that's your problem. You can't believe everything you read, especially not in "UNIX World". They try hard, but apparently need an editor who's a bit more knowledgeable and can catch goofs like this. I read it anyway. I don't really know why. The actual definition of Virtual Memory involves the concept of allowing programs to believe that they are running at a particular address, when in fact they may actually be at a completely different *physical* address. The definition the author of the article (and the UW editor) are mistakenly using involves the concept of *demand paging*. System V has always had virtual memory (on real architectures). It's just that the sharing of memory by more programs than would physically fit all at once was done by a process called "swapping". This involved the migration of entire processes between main memory and "the swapper". Since SVR2.1, about something like FOUR YEARS AGO, System V has supported the other popular method, called "demand paging". This is where the process is broken up into chunks, called "pages", and the pages are moved in and out of main memory "on demand". Anyway, even the "swapping" style of memory sharing uses Virtual Memory. The process may be loaded onto an entirely different memory card from one second to the next. The program doesn't even know. Using "demand paging", not all of the pages must be in memory at the same time, just those that are "currently" needed. They don't have to be kept in contiguous physical memory. > (1) If there is no VM, how does the operating system, bring the programs > from secondary storage to main for execution.(System V ) This question really has little or nothing to do with VM. One can very easily accomplish the simple loading of programs in the same way that something like MS-DOS does. > (2) How does MS-Dos solve the above problem? It knows where it has some memory not currently in use and causes disk reads to bring the code from disk into that "free" memory, marking the memory as no longer free. When the program exits, MS-DOS (normally) marks the memory as free once again. > (3) I have comments like Unix needs at least 4M of main memory? > Is it for all the daemons to run? That really depends on the version of UNIX, the system (hardware) involved, and the demands placed on it. For example, the Motorola Delta systems require that you have 4Meg for the current version of SVR3. The reason is that the installation procedure boots from tape into a ~2Meg RAM Disk. After installation, unless you are running Remote File Sharing, and with a bit of tuning, you can run quite comfortably in 2Meg. It does depend, of course, on what you are trying to do. If you want to run GNU Emacs or something else huge, you'd better get more memory than you can afford. :-) -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "Failure is one of the basic Freedoms!" The Doctor (in Robots of Death)
ron@ron.rutgers.edu (Ron Natalie) (10/11/88)
The article is inaccurate. System V has virtual memory of almost any definition. Originally System V had problems with virtual memory. There are two differing definitions of Virtual Memory. The more liberal definition says that Virtual Memory provides for swap extension of real memory and some sort of address translation. UNIX has always done this. The more restrictive definition is that some mechanism such as paging or segmented swapping exists as well. The difference is summarized in the following. Suppose you have 1 M of real memory and you want to run a 2 M process. Prior to recent system V versions, you were out of luck. It always expected to load a whole process as a unit. On paging systems, it only needed to bring in the parts needed for the execution of the current instruction. The virtual memory argument was best summarized by Bruce Crabill of the University of Maryland. "It ain't virtual unless it's not all there." This means that the liberal definition is kind of weak if you have to have real memory to back your virtual memory for any give process. -Ron Of course, they may have meant VM as Virtual Machine. It is doubtful that anything other than AIX/370 is going to support that.
chris@spock (Chris Ott) (10/11/88)
heiby@mcdchg.UUCP (Ron Heiby) writes: > kannan@emx.UUCP or nataraj@happy.cc.utexas.edu writes: > > I read an article in UNIX World comparing system V and AIX. It clearly > > stated that System V did not have VM(Virtual Memory concept). > Well, that's your problem. You can't believe everything you read, > especially not in "UNIX World". They try hard, but apparently need an > editor who's a bit more knowledgeable and can catch goofs like this. > I read it anyway. I don't really know why. > > The actual definition of Virtual Memory involves the concept of allowing > programs to believe that they are running at a particular address, when > in fact they may actually be at a completely different *physical* address. Wrong. The actual concept of virtual memory is the ability to allow programs to use more memory than the machine physically has by swapping the least recently used pages to secondary storage. For instance, if your program wants to use 50 megabytes of memory and your machine only has 4 megabytes of main memory, you need store the excess on the disk until it is needed again by the program. If your machine can do this, it has virtual memory. This is usually (if not always) transparent to the program. Your definition is only a part of today's virtual memory systems. > The definition the author of the article (and the UW editor) are mistakenly > using involves the concept of *demand paging*. System V has always had > virtual memory (on real architectures). It's just that the sharing of > memory by more programs than would physically fit all at once was done > by a process called "swapping". This involved the migration of entire > processes between main memory and "the swapper". Since SVR2.1, about > something like FOUR YEARS AGO, System V has supported the other popular > method, called "demand paging". This is where the process is broken up > into chunks, called "pages", and the pages are moved in and out of main > memory "on demand". Close, but not quite. Demand paging involves only the code portion of the program. Instead of loading the whole program immediately when is is executed, only the initially needed pages are loaded and new pages are "paged in" as they are needed. This way, the program starts much faster. What you have described here is actually the way virtual memory works. By the way, I'm pretty sure you need a virtual memory system to be able to implement demand paging. > Anyway, even the "swapping" style of memory sharing > uses Virtual Memory. Wrong. The definition swapping depends on what type of memory you have (virtual or non-virtual). On non-virtual memory systems, swapping occurs when a process needs to execute, but there isn't enough memory to bring it in. Another process that is not currently executing is swapped out (to secondary storage) to make room for the new process. Note that the ENTIRE process is swapped out, not just pieces of it, as is true with a virtual memory system. Swapping in a virtual memory system refers to the swapping of those "chunks" or pages to and from secondary storage. Most people actually call this "paging", since only pages of the process are swapped, rather than the whole process. We say that a process is "swapped out" when all of its pages have been placed on secondary storage. This usually only occurs on a heavily loaded system. > Using "demand paging", not all of the pages must be in memory at the same > time, just those that are "currently" needed. They don't have to be kept > in contiguous physical memory. Again, this is the definition of virtual memory. > Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix --Chris ------------------------------------------------------------------------------- Chris Ott Computational Fluid Mechanics Lab Just say "Whoa!!" and University of Arizona vote for Randee!! Internet: chris@spock.ame.arizona.edu UUCP: {allegra,cmcl2,hao!noao}!arizona!amethyst!spock!chris -------------------------------------------------------------------------------
pjh@mccc.UUCP (Pete Holsberg) (10/12/88)
In article <13133@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: ...kannan@emx.UUCP or nataraj@happy.cc.utexas.edu writes: ...> I read an article in UNIX World comparing system V and AIX. It clearly ...> stated that System V did not have VM(Virtual Memory concept). Why is this VM stuff on comp.os.CPM???? -- Pete Holsberg UUCP: {...!rutgers!}princeton!mccc!pjh Mercer College CompuServe: 70240,334 1200 Old Trenton Road GEnie: PJHOLSBERG Trenton, NJ 08690 Voice: 1-609-586-4800
mark@hubcap.UUCP (Mark Smotherman) (10/12/88)
In article <835@amethyst.ma.arizona.edu>, chris@spock (Chris Ott) writes: > > heiby@mcdchg.UUCP (Ron Heiby) writes: > > The actual definition of Virtual Memory involves the concept of allowing > > programs to believe that they are running at a particular address, when > > in fact they may actually be at a completely different *physical* address. > > Wrong. The actual concept of virtual memory is the ability to allow > programs to use more memory than the machine physically has by swapping ^^^^^^^^^^^^^^^ > the least recently used pages to secondary storage. It's a shame that we can't agree on terminology. I believe that we have been too heavily influenced by marketing types. The older academic textbooks agree with Ron. E.g., A.M. Lister (1st ed. 1975, - 3rd ed. 1984) states "... the programmer 'sees', and programs for, a _virtual memory_ whose characteristics differ from those of the real memory." Lister then goes on to a section on "Implementation of Virtual Memory" that _begins with_ base and limit registers (i.e. GE-635, Honeywell 6000, Univac 1100, CDC 6600, etc.). Obviously these machine did not support demand paging. However, Chris may just be out of school and may have just taken an OS course using a textbook such as Silberschatz and Peterson (alt. ed. 1988). These authors state "Virtual memory is a technique that 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." I have fun in class with those of the second persuasion when I bring up the DECsystem 10 model KI10, which has a 24-bit _physical address_ and an 18-bit _virtual address_! DEC used a paging scheme and a large physical memory to balance these systems and extend the life of the 10 series - thus, as the CPU got faster it needed more memory and more ready processes, yet for compatibility purposes the older 18-bit software still had to run. According to your definition, Chris, is this _paging_ system a virtual memory system??? > > > The definition the author of the article (and the UW editor) are mistakenly > > using involves the concept of *demand paging*. > > ... It's just that the sharing of memory by more programs than would > > physically fit all at once was done by a process called "swapping". > > Close, but not quite. Demand paging involves only the code portion of ^^^^^^^^^^^^^^^^^^^^^ > the program. Page only the code portion? News to me! > > > Anyway, even the "swapping" style of memory sharing > > uses Virtual Memory. > > Wrong. The definition swapping depends on what type of memory you > have (virtual or non-virtual). > Swapping in a virtual memory system refers to the swapping of those > "chunks" or pages to and from secondary storage. Most people actually call > this "paging", since only pages of the process are swapped, rather than the > whole process. The base and limit scheme mentioned above uses swapping. > > > Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix > > > Chris Ott > Computational Fluid Mechanics Lab Just say "Whoa!!" and > University of Arizona vote for Randee!! -- Mark Smotherman, Comp. Sci. Dept., Clemson University, Clemson, SC 29634 INTERNET: mark@hubcap.clemson.edu UUCP: gatech!hubcap!mark
mark@hubcap.UUCP (Mark Smotherman) (10/12/88)
In a previous posting I mentioned that base and limit schemes are viewed as virtual memory. I neglected to point out that the single base/limit pair is the trivial case of segmentation (e.g. GE-635) and that two base/ limit pairs is the n=2 case of segmentation (one segment contains code and the other segment contains data, e.g. UNIVAC 1108). The Intel 8086 is an example of four segments without limit protection. Note that if there are multiple segments and if a missing segment interrupt is generated when a non-resident segment is referenced (and if side-effects on registers can be undone, e.g. autoincrement), then not all of a program has to be resident in physical memory for execution to proceed. Thus demand segmentation is possible. To say that virtual memory requires demand _paging_, I would have to reclassify all the segmented machines (also the B5500). If segmentation is not a virtual memory technique, then what is it? -- Mark Smotherman, Comp. Sci. Dept., Clemson University, Clemson, SC 29634 INTERNET: mark@hubcap.clemson.edu UUCP: gatech!hubcap!mark
chris@spock (Chris Ott) (10/12/88)
mark@hubcap.UUCP (Mark Smotherman) writes: > > In article <835@amethyst.ma.arizona.edu>, chris@spock (Chris Ott) writes: > > Close, but not quite. Demand paging involves only the code portion of > ^^^^^^^^^^^^^^^^^^^^^ > > the program. > > > Page only the code portion? News to me! I didn't mean that only the code portion is paged, I meant that only the code portion is _demand paged_. Here, I made a slight mistake. It's not just the code portion, it's the _text_ portion. This includes code _and_ initialized (usually read-only) data. Sorry. Anyway, as in the Sun Commands Reference manual, under ld(1): -z Arrange for the process to be loaded on demand from the resulting executable file rather than preloaded. i.e. Rather than loading the entire file into memory at once, like some systems do, load the pages as they are needed. This only applies to the text portion of the program, not data, like local variables of subroutines and such. By the way, I also have a Data General manual that describes demand paging, and it says almost the same thing. If you want me to dig it up and post what it says, let me know. > To say that virtual memory requires demand _paging_, I would have to > reclassify all the segmented machines (also the B5500). I didn't say that. I said that demand paging requires virtual memory. I also said that I'm not sure this is true, although I can't imagine right off the top of my head how a system could do it without virtual memory. > If segmentation > is not a virtual memory technique, then what is it? It depends on what kind of segmentation it is and the capabilities of your processor. Simple mapping from a logical address to a physical address (making the process think it's in one place in memory when it's really in a totally different place) is _not_ virtual memory, as was asserted by Ron Heiby in his article. If the segmentation allows your process to think it's using 50 megabytes of memory when there are only 4 megabytes of main memory in your computer, then yes, that's virtual memory. There are many architectures that use a 68000 with hardware memory management (usually base-limit style) that are not virtual memory systems. Here, we have an Exormacs chassis with an 8Mhz 68000 and hardware memory management (logical to physical address mapping). To the best of my knowledge, this system has _never_ been advertised as a virtual memory system. According to Ron's definition, it _is_ a virtual memory system. If you correctly remember, the big deal about the 68010 was that it could continue an instruction after it was interrupted by a bus error, thus giving it _virtual memory_ capability. When the 68010 tries to access a page that isn't currently in memory, the external hardware gives it a bus error signal. Then, the 68010 can stop what it was doing, go to the disk, bring in the page that it tried to access, and restart the instruction right where it left off. If all the pages in main memory are used, it finds another page, puts it on the disk, and "pages in" the page it needs. The 68000 could never do this, because it cannot restart an instruction that was interrupted by a bus error. Yet, there are many 68000 systems that can do what Ron said a virtual memory system does. > These authors state "Virtual memory is a technique that 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." Basically this definition of virtual memory is correct, and I'm pretty sure I would consider any system that can do this a virtual memory system. If you still don't believe me, let's take this to comp.arch and ask them what they think. Chris ------------------------------------------------------------------------------- Chris Ott Computational Fluid Mechanics Lab Just say "Whoa!!" and University of Arizona vote for Randee!! Internet: chris@spock.ame.arizona.edu UUCP: {allegra,cmcl2,hao!noao}!arizona!amethyst!spock!chris -------------------------------------------------------------------------------
spaf@cs.purdue.edu (Gene Spafford) (10/12/88)
The definition I use in teaching OS courses is the following: If the address presented to the system may be bound to a physical address different from that seen by the program, you have virtual memory. That is, if the software generates some address like 5 for a storage location, and if the binding to a physical address COULD POSSIBLY be to a hard physical address different from 5, then that implies virtual memory (let's not try to twist this to include fault handling, etc.). Virtual memory includes, possibly, pages, segments, overlays, base register addressing, and some forms of swapping. Virtual memory does not mean that the virtual address range is bigger than the physical address range -- it could be smaller, as in the case of old CDC machines that had megabytes of memory but could only run program images of a few 100K. Swapping is not per se virtual memory. If you swap images in and out of the exact same addresses, and if there is no translation of the addresses after any swap, then that is not virtual memory. The "virtual" means that the memory looks as if it were the range of physical addresses specified by the program. That's how I've taught it in OS courses at both Purdue and Georgia Tech, and that's consistent with many OS texts....
terryl@tekcrl.CRL.TEK.COM (10/13/88)
In article <837@amethyst.ma.arizona.edu> chris@spock.ame.arizona.edu (Chris Ott) writes: > >mark@hubcap.UUCP (Mark Smotherman) writes: >> > In article <835@amethyst.ma.arizona.edu>, chris@spock (Chris Ott) writes: >> > Close, but not quite. Demand paging involves only the code portion of >> ^^^^^^^^^^^^^^^^^^^^^ >> > the program. >> >> >> Page only the code portion? News to me! > > I didn't mean that only the code portion is paged, I meant that only >the code portion is _demand paged_. Here, I made a slight mistake. It's >not just the code portion, it's the _text_ portion. This includes code >_and_ initialized (usually read-only) data. Sorry. Anyway, as in the Sun >Commands Reference manual, under ld(1): > > -z Arrange for the process to be loaded on demand from the resulting > executable file rather than preloaded. > >i.e. Rather than loading the entire file into memory at once, like some >systems do, load the pages as they are needed. This only applies to the >text portion of the program, not data, like local variables of subroutines >and such. Uh, not quite, Mr. Ott. You can demand page the DATA portion of a process. Almost all of the various derivatives of 4.n BSD (n >= 0) I've looked at do support demand paging for both the data and the stack portion. In fact, here's a portion of the ld(1) man page on a VAX(slightly paraphrased): -z Arrange for the process to be loaded on demand from the resulting executable file (413 format) rather than preloaded. This is the default. Results in a 1024 byte header on the output file followed by a text and data segment each of which have size a multiple of 1024 bytes..... The reason for the "multiple of 1024 bytes..." is for demand paging; it makes it easier. Now, it may be that the Sun only supports demand paging for the text portion of a process (I have absolutely no idea, for I have no experience with any of Sun's products...), but since they were so heavily based on 4.2 BSD (now a mixture of 4.2 and Sys V), I doubt that they would take out the demand paging of data. Once you've got it for text, it's not that difficult to implement it for data and stack (after all, parts are parts, blocks are blocks, memory is memory, etc... (-:). In order to make myself a little more clear, here's what a generic 4.2 system does for demand paging: The text and data are demand paged FROM THE FILE where the program resides (but ONLY for the first page fault); bss and stack pages are demand paged, also, but they are a paged differently than text and data. bss and stack pages are marked as zero-fill-on-demand (i.e. the first time a process references a bss or stack page, 4.2 will map it into the process's address space, zeroing the contents of the page first). Now, regardless of the type of page, when a page is paged out, it is written to a swap device; when that page is referenced again, it will be paged in from the same swap device. This is true for a generic 4.2 system, though I've seen a couple of systems that NEVER write out text pages (since they will never be modified), and demand page the text page from the file where the program resides yet again. I hope this clears things up somewhat.....
jcb@lfcs.ed.ac.uk (Julian Bradfield) (10/13/88)
In article <835@amethyst.ma.arizona.edu> chris@spock (Chris Ott) writes: >heiby@mcdchg.UUCP (Ron Heiby) writes: >> The actual definition of Virtual Memory involves the concept of allowing >> programs to believe that they are running at a particular address, when >> in fact they may actually be at a completely different *physical* address. > Wrong. The actual concept of virtual memory is the ability to allow >programs to use more memory than the machine physically has by swapping >the least recently used pages to secondary storage. For instance, if your Not necessarily. You could have more real memory than total virtual memory, and still have a virtual memory system. (One of the main points of virtual memory is to increase the apparent size of memory, but it's not a necessary part of the concept.) > Swapping in a virtual memory system refers to the swapping of those >"chunks" or pages to and from secondary storage. Most people actually call >this "paging", since only pages of the process are swapped, rather than the >whole process. We say that a process is "swapped out" when all of its pages >have been placed on secondary storage. This usually only occurs on a heavily >loaded system. I call paging paging and swapping swapping! For example, MVS pages memory; but there is also the concept of swapping out an address space, which puts the whole (private part of the) address space on to secondary storage, together with the page tables, with the result that you can't do cross-memory communication with the address space, and no task in it can be dispatched. The traditional Unix swapping concept has much the same effect, does it not?
mark@hubcap.UUCP (Mark Smotherman) (10/13/88)
In article <5085@medusa.cs.purdue.edu>, spaf@cs.purdue.edu (Gene Spafford) writes: > Swapping is not per se virtual memory. If you swap images in and out > of the exact same addresses, and if there is no translation of the > addresses after any swap, then that is not virtual memory. This is how IBM OS/360 TSO worked. Since the base registers could be accessed (and changed!) by the user, they could not be used for memory relocation. Essentially, they were used to offload relocation from the loader (poor choice, since loader does relocation once and for all, while base registers incur an execution time penalty each time the instruction is executed) and to provide address abbreviation (fairly good choice, since 16 bits were used as the base:offset field in the instruction instead of 24; however, catenation of high-order bits as in the old PDP-8 is sometimes better than addition since it avoids the addition time - the drawback is the corresponding alignment requirement.) To distinguish between swapping with execution-time relocation and the IBM 360 technique of transfer to and from the same addresses, the latter was called roll-out/roll-in. The OS effect was that there was no load balancing between multiple TSO partitions. Once a command interpreter was initiated, it was bound to its initial partition for the duration of the terminal session. Thus a pathological case could be that half the users are allocated to partition A, half to partition B - then if it so happened that all the partition A users logged off or were in extended terminal I/O wait, then all the partition B users still contended for that one partition. Fred Brooks has indicated that early 360 design hopes were that the base registers could be used for execution-time relocation. -- Mark Smotherman, Comp. Sci. Dept., Clemson University, Clemson, SC 29634 INTERNET: mark@hubcap.clemson.edu UUCP: gatech!hubcap!mark
chasm@killer.DALLAS.TX.US (Charles Marslett) (10/13/88)
In article <251@acheron.UUCP>, clarke@acheron.UUCP (Ed Clarke) writes: > 1. . . . AIX uses VRM which is a sort > of low level idealized machine that comes between AIX and the true hardware. > It complicates life quite a bit when you want to add support for non > standard devices. I think it's supposed to disapear in the future. Are you serious? It probably has its flaws, but the idea that every copy of the OS has to be relinked every time any hardware is changes went out of favor everywhere but here in Unix-land years ago. I was of the opinion, last I read anything of the AIX docs, that the VRM/dynamic drivers system was AIX's most useful "enhancement". (Even Messy-DOS is simpler and more versatile at the same time than the Unices I have looked at recently (:-). > 2. MS-Dos has neither. It's a program loader that runs in 8086/8088 > mode (< 1 Meg). Yeah, it'll run on 80286/80386 machines, but it doesn't > take advantage of any of the extended features. Actually, to repeat myself, user loadable drivers and the much maligned "BIOS" create a reasonable virtual machine (virtual memory, . . . lets talk about real computers now . . .). > Ed Clarke > uunet!bywater!acheron!clarke Charles Marslett chasm@killer.dallas.tx.us <-- apply all standard disclaimers <-- since I KNOW nothing!
wallace@cme-durer.ARPA (Evan Wallace) (10/13/88)
In article <5085@medusa.cs.purdue.edu>, spaf@cs.purdue.edu (Gene Spafford) writes: > The definition I use in teaching OS courses is the following: > > If the address presented to the system may be bound to a physical > address different from that seen by the program, you have > virtual memory. That is, if the software generates some address > like 5 for a storage location, and if the binding to a physical > address COULD POSSIBLY be to a hard physical address different > from 5, then that implies virtual memory (let's not try to > twist this to include fault handling, etc.). This is mapped memory and not virtual, since the memory accessed is indeed existant. > Virtual memory does not mean that the virtual address range is bigger > than the physical address range -- it could be smaller, as in In "An Introduction to Operating Systems" by Deitel virtual storage is defined to be a storage area larger than the primary storage area (memory). This is in direct contradiction with G. Spafford's definition, but in complete agreement with common sense. Also this definition is even in my webster's dictionary with a 1966 date of origin.? > That's how I've taught it in OS courses at both Purdue and > Georgia Tech, and that's consistent with many OS texts.... It's unfortunate that this kind of thing gets passed on to students who will then continue its propagation.
woods@ixpierre.uucp (Greg A. Woods) (10/14/88)
In article <837@amethyst.ma.arizona.edu> chris@spock.ame.arizona.edu (Chris Ott) writes: > mark@hubcap.UUCP (Mark Smotherman) writes: > > > In article <835@amethyst.ma.arizona.edu>, chris@spock (Chris Ott) writes: > > > Close, but not quite. Demand paging involves only the code portion of > > > the program. > > > > Page only the code portion? News to me! > > I didn't mean that only the code portion is paged, I meant that only > the code portion is _demand paged_. I had the distinct impression that this was called direct paging. What is commonly called "virtual" memory is actually more properly referred to as "demand paged virtual memory". Just to get your goat, you might like to know that MS-Windows (and I presume MS-DOS 4.0 also do direct paging, though it's done with segments :-). Unix System V/386 Release 3.2 (also called 386/ix Release 2.0) will have direct paging (as well as continuing to implement demand paged virtual memory). At least that's what they tell me :-). -- Greg Woods. UUCP: utgpu!woods, utgpu!ontmoh!woods, {ontmoh,tmsoft,telly}!ixpierre!woods VOICE: (416) 443-1743 [h] LOCATION: Toronto, Ontario, Canada
spaf@cs.purdue.edu (Gene Spafford) (10/14/88)
In article <664@cme-durer.ARPA> wallace@cme-durer.ARPA (Evan Wallace) writes: >In article <5085@medusa.cs.purdue.edu>, spaf@cs.purdue.edu (Gene Spafford) writes: >> The definition I use in teaching OS courses is the following: >> >> If the address presented to the system may be bound to a physical >> address different from that seen by the program, you have >> virtual memory. That is, if the software generates some address >> like 5 for a storage location, and if the binding to a physical >> address COULD POSSIBLY be to a hard physical address different >> from 5, then that implies virtual memory (let's not try to >> twist this to include fault handling, etc.). > >This is mapped memory and not virtual, since the memory accessed is >indeed existant. Indeed. I should have stated that the reference could also map to a fault, indicating that the location is not currently bound to a physical location. The fault MAY result in a new binding being created and the reference retried without any action (or participation) by the faulting task. >> Virtual memory does not mean that the virtual address range is bigger >> than the physical address range -- it could be smaller, as in > >In "An Introduction to Operating Systems" by Deitel virtual storage >is defined to be a storage area larger than the primary storage >area (memory). This is in direct contradiction with G. Spafford's >definition, but in complete agreement with common sense. Also this >definition is even in my webster's dictionary with a 1966 date of >origin.? Neither Webster nor Deitel are necessarily references to quote to me, especially if you wish to prove a point in operating systems. Deitel doesn't address a number of things very well -- that's why we don't use it here as a text, and Webster never even saw a computer. :-) I'm not going to waste my time by going through the 20+ OS books I have on my shelf that I use for references just to tally how many define it my way. I waded through those and over 100 articles a few years back when I did my MS thesis on memory management, and I've been through all this stuff when I wrote and defended the OS for my PhD, and when I teach OS, etc. I *know* what virtual memory is. The definition I gave happens to cover the memory scheme on systems your definition doesn't -- like TSO on a 360, old NOS on a CDC 6600, and various DEC OS systems on their earlier PDP machines. If the program presented an address to the hardware as if it referred to the physical memory, and if the firmware may possibly bind that to a different physical address, then it is virtual memory. The virtual store (to use Finkle's terminology) does not have to be bigger than the physical memory on the machine; it may be smaller. Virtual memory for object-oriented systems, for instance, tends to have lots of small virtual address spaces coresiding in a large physical space. >> That's how I've taught it in OS courses at both Purdue and >> Georgia Tech, and that's consistent with many OS texts.... > >It's unfortunate that this kind of thing gets passed on to students >who will then continue its propagation. It's unfortunate that people don't understand what virtual memory is, and think that the way it is done in Unix is the only correct way. Too many people think they understand virtual memory, processes, and OS design simply because they understand Unix and MS-DOS. It's unfortunate that this kind of thing gets passed on to students who will then continue its propagation. Happily, I'm not contributing to such brain rot...and neither are any of my students. -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
alexande@drivax.UUCP (Mark Alexander) (10/15/88)
In article <5085@medusa.cs.purdue.edu> spaf@cs.purdue.edu (Gene Spafford) writes: >The definition I use in teaching OS courses is the following: >If the address presented to the system may be bound to a physical >address different from that seen by the program, you have >virtual memory. You seem to be saying that if you're using the address translation hardware of the computer (like the LDT and GDT in protected mode of the <gag, barf> 286), you've got virtual memory. This may be a fine definition for school, but out here in the real world, where we have to deal with nasty stuff like marketing & sales, it wouldn't work. We sell an operating system that uses the protection and address translation features of the 286, 386, V60, and 68010/68451 hardware, but if we tried to tell potential customers "our operating system does virtual memory!", we'd be laughed at, or accused of false advertising. When we get around to implementing swapping or demand paging (depending on the processor), then and only then will we be able to make that claim. -- Mark Alexander (UUCP: amdahl!drivax!alexande) "Bob-ism: the Faith that changes to meet YOUR needs." --Bob (as heard on PHC)
mlelstv@faui44.informatik.uni-erlangen.de (Michael van Elst ) (10/17/88)
In article <6693@ut-emx.UUCP> kannan@emx.UUCP or nataraj@happy.cc.utexas.edu writes: > I read an article in UNIX World comparing system V and AIX. > It clearly stated that System V did not have VM(Virtual Memory concept). Of course, System V _uses_ virtual memory. > > (1) If there is no VM, how does the operating system, bring the programs > from secondary storage to main for execution.(System V ) I don't see the point. VM is used to run large (or multiple) programs in a limited real memory. The secondary storage is problem of the file system. You load programs from a code-file, that contains the code and data segments and some other useful information like stacksize. > > (2) How does MS-Dos solve the above problem? MS-DOS has no VM. It runs all programs in a single address space for there is only one process. Loading of programs is ... (see answer to 1) > > (3) I have comments like Unix needs at least 4M of main memory? > Is it for all the daemons to run? No. UNIX is rather large operating system. The kernel is some 100kbytes large and you need buffer space to speed up disk i/o. You need approx. 1.5M to 2M for a single user workstation and 1M for each other user. So 4M is an average size for an UNIX machine but not required. The deamons are programs that handle regular system activities like printer spooling. For UNIX handles virtual memory, those processes are swapped out on disk and don't need real memory unless they really DO anything useful. Michael van Elst E-mail: UUCP: ...uunet!unido!fauern!faui44!mlelstv
R_Tim_Coslet@cup.portal.com (10/18/88)
In <5102@medusa.cs.purdue.edu> spaf@cs.purdue.edu (Gene Spafford) Writes: >In article <664@cme-durer.ARPA> wallace@cme-durer.ARPA (Evan Wallace) writes: >>In article <5085@medusa.cs.purdue.edu>, spaf@cs.purdue.edu (Gene Spafford) writes: [much deleted] >teach OS, etc. I *know* what virtual memory is. > >The definition I gave happens to cover the memory scheme on systems >your definition doesn't -- like TSO on a 360, old NOS on a CDC 6600, [more deleted] >It's unfortunate that people don't understand what virtual memory is, >and think that the way it is done in Unix is the only correct way. Too [rest deleted] This whole discussion is an example of how NOTHING is really standard in computers and how people familiar with one usage of a term get all confused (and ocasionally violent) in responce to an unusual or unfamiliar usage of the same term. I still remember the time I read some CDC (I think) documentation and kept encountering the term "Stack" used in a manner that did not seem to make sense ("everyone" knows that a "stack" is a push/pop data structure usually used for saving return addresses, etc. on). I had read nearly the whole document before I realized that that document was using the term "Stack" to refer to what I was used to calling a "Memory Bank". Had to reread the whole document to understand it, then :-( So as far as I am concerned... Both definitions of "virtual memory" are valid (within the context in which they are defined). Although I tend to agree that "virtual memory" only really requires that the program "think" it is running in a different memory than may actually be present on the hardware (and not have to do anything "on its own" to manage the differences) regardless of whether that "virtual memory" is larger or smaller than the "physical memory". R. Tim Coslet Usenet: R_Tim_Coslet@cup.portal.com BIX: r.tim_coslet
tvf@bmt.UUCP (Thomas V. Frauenhofer) (10/25/88)
In article <664@cme-durer.ARPA> wallace@cme-durer.ARPA (Evan Wallace) writes: >In article <5085@medusa.cs.purdue.edu>, spaf@cs.purdue.edu (Gene Spafford) writes: >> Virtual memory does not mean that the virtual address range is bigger >> than the physical address range -- it could be smaller, as in > >In "An Introduction to Operating Systems" by Deitel virtual storage >is defined to be a storage area larger than the primary storage >area (memory). This is in direct contradiction with G. Spafford's >definition, but in complete agreement with common sense. Also this >definition is even in my webster's dictionary with a 1966 date of >origin.? In deference to what you say, consider the BBN Butterfly. A 68000 can only address 16 Meg tops. Special hardware facilitates being able to address memory on other processors, so your physical address space is > 16 Meg. This is clearly an example where the virtual memory space is SMALLER than the physical memory space (and I learned this in my operating systems course). > >> That's how I've taught it in OS courses at both Purdue and >> Georgia Tech, and that's consistent with many OS texts.... > >It's unfortunate that this kind of thing gets passed on to students >who will then continue its propagation. On the contrary, let's here it for professors who challenge their students to be at the cutting edge (like mine). One of my pet beefs with software engineers (of which I'm as guilty as anyone) is that once we've figured out one way that something works, we close our minds to other methods/techniques to be used or ways it could work. "Intuitive" reasoning is not always the best way to approach a topic. ----- Tom Frauenhofer ...!rutgers!rochester!kodak!bmt!tvf BLOOM: You can't kill the actors! They're human beings! BIALYSTOCK: Oh yeah? You ever eat with one? -- Tom Frauenhofer ...!rutgers!rochester!kodak!bmt!tvf BLOOM: You can't kill the actors! They're human beings! BIALYSTOCK: Oh yeah? You ever eat with one?