Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!ncrlnk!ncrcae!ncr-sd!hp-sdd!ucsdhub!ucsd!rutgers!mailrus!ncar!noao!amethyst!spock!chris From: chris@spock (Chris Ott) Newsgroups: comp.os.misc Subject: Re: a very naive Question??? Message-ID: <835@amethyst.ma.arizona.edu> Date: 11 Oct 88 03:40:47 GMT Article-I.D.: amethyst.835 Sender: news@amethyst.ma.arizona.edu Reply-To: chris@spock (Chris Ott) Organization: Computer-Aided Engr. Lab (CAEL), University of Arizona, Tucson Lines: 78 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 -------------------------------------------------------------------------------