herbie@polaris.UUCP (Herb Chong) (10/27/85)
>From: dvadura@watdaisy.UUCP (Dennis Vadura) >Perhaps the question to ask is do we need disk paging? >With large memories becoming available rolling pages out to disk may become >unneccessary, but the concept of virtual memory and its associated attributes >is probably still useful. it depends upon the ratio of number of users * average virtual memory each --------------------------------------------- total real memory available if this ratio is small, then no disk paging is required. if this ratio is large, then disk paging is required. a 32M processor running 400 users at 2M each must page to disk. a 256M processor running the same users will still page, but not nearly as much. remember that the processors with these large memories usually are very fast and support many users. if only a few users are supported, then paging is something that is unneccesary. >From: rcd@opus.UUCP (Dick Dunn) >First response: How near? 1 Mbit chips are real but not quite big-time >commercial stuff yet (that means: not CHEAP yet), but suppose that they >are. 256 Mb = 256*8 = 2K of these chips, which is a fair space-heater in >any technology. In larger machines, maybe yes; we're a few years away in >small machines. IBM has at least two announced models of CPU's available with 256M real, though it's treated in a weird fashion. it is not as fast as the usual main memory. for those of you who remember the s/360's with core, some models had a small (64K?) amount of fast core and the rest was slow core. the same things are true these days. >VM sets the "hard limit" of >a process address space independently of the actual physical memory on the >machine, so you don't have to go out and buy more memory to run a program >with a large address space--it just runs slower. (Yes, in some cases it >runs intolerably slower. If that happens, go buy more memory, obviously.) the original reason for VM was what dick says. remember though that today's main reason is support a lot of users with medium max memory requirements but small working sets. why use expensive main memory for idle pages when you can put a dispatchable user in there instead. of course, there has to be enough CPU power around to make processes dispatchable often enough. >Third response: Decrease program startup? (Tentative.) If you insist on >everything being in physical memory, you gotta load the whole program >before you start execution. Might take a long time--the case of interest >is where a program has gobs of seldom-used code. The counter to this >response is that if a program has poor locality of reference--which is >common during startup!--the VM paging behavior is essentially to load a >large part of the program but in random order, which can make it take >longer than loading all of it sequentially. it turns out that for many programs (observation only, no proof) that single block read of the binary is faster than page faulting it in. it depends on how smart your program loader/process starter is and your disk hardware. >Fourth response: Maybe VM is appropriate to a certain balance of process >size, memory cost and size, and backing store cost/speed. You could argue >that larger machines are now outside the domain of that particular set of >tradeoffs. Smaller machines are not. larger machines ten to run many users. an IBM 3084 processor with 256M would be supporting about ~500 users online (order of magnitude figure) so you still need a lot of paging. also, what about memory mapped filesystems? you certainly don't want a large file in memory all the time unless the ratio i mentioned above will support it. >From: brooks@lll-crg.ARpA (Eugene D. Brooks III) >I'm sorry I was not precise enough. The question was meant to be do we need >disk paging? The much needed firewall protection and address space shareing >for programs in a multiprocessor can be provided by a simple {base,limit} >segmentation scheme. One or course needs several sets of such registers >to establish the several segments, code, static data, stack, shared static >data, ... that one needs in a program. Do we really need the page oriented >virtual memory systems that occur in todays micros and mini computers? If >we have more than enough physical memory, do we need the overhead associated >with the page mapping hardware? It is difficult to make such hardware operate >at supercomputer speeds and poses severe difficulties for non bus oriented >architectures (large N multiprocessors). if you are supporting many users or many processes, then you will still need disk paging. >From: chuck@dartvax.UUCP (Chuck Simmons) >Another reason for virtual memory is that segmented architechtures can >make programming easier. For example, some programs want to have multiple >stacks (eg our PL1 compiler). By setting up each stack as a segment, >the compiler programmer can easily and efficiently allocate storage on >any stack. Our current pl1 compiler, written before we had a segmented >architechture, must spend a lot of time worrying about stack collisions. >When one of these occur, it must shuffle the stacks around in core to move >them away from each other. does this make interprocess communication messy when you have to talk about data in segments here and there? >From: franka@mmintl.UUCP (Frank Adams) >What leads either of you to believe that 256M will be enough to run your >programs? Memory used by programs expands to use the space available. >There was a time, not so long ago, when 256K was a lot of memory, and >people didn't understand how any program could use more than 16M. If >memory becomes sufficiently cheap, there are time/space tradeoffs which >can be made to use large blocks of it. if you go into large commercial DP shops, you will find that to be a major concern of theirs. large terminal networks require massive amounts of memory to keep track of them all. large database systems will try to keep as much data in memory as possible to speed up transaction processing. there is never enough memory. >Or, for a second response, if memory becomes cheap enough, what do you >need *disks* for? You will need a hardware solution to preserve memory >in the event of system/power crashes, of course. you could always use non-volatile semiconductor memory with a sufficent battery backup to keep it alive until you could put it onto tape (1/2 8-)). >From: rentsch@unc.UUCP (Tim Rentsch) >It is interesting to note that 10 years ago or so, all large systems >had virtual memory whereas small systems did not. i don't think all is right, i think more than 50% would be more accurate. >Now the largest systems (e.g., Cray 2) do not have virtual memory, >whereas it is more and more common for small systems ("microprocessors", >and I use the term in quotes) to have virtual memory. remember that a Cray-2 is meant to be used to run only a few programs at a time. the available real memory per process is much higher than for a general purpose computer system. the Cray is hardly representative of the "typical" computer system. Herb Chong... I'm still user-friendly -- I don't byte, I nybble.... New net address -- VNET,BITNET,NETNORTH,EARN: HERBIE AT YKTVMH UUCP: {allegra|cbosgd|cmcl2|decvax|ihnp4|seismo}!philabs!polaris!herbie CSNET: herbie.yktvmh@ibm-sj.csnet ARPA: herbie.yktvmh.ibm-sj.csnet@csnet-relay.arpa
eugene@ames.UUCP (Eugene Miya) (11/03/85)
I mailed my initial response directly to Eugene Brooks, and I am surprised that there is so much flaming on this topic. I think the "applications fill the available memory" argument is the correct one. The problem with these massive memory machines comes with Unix. Consider in the not to distant future machine with more memory than the C-2 (which borders on this problem). For argument sake let's say 2-4 Gigawords of physical memory. Consider two user processes which take up slightly more than 50% of physical memory. Let's suppose process 1's time is up and must get swapped out. Well, how long does it take to swap 2+ GWs? [16 GBs] Think about this at IBM channel speeds and we are talking whole seconds to swap by which time with an unmodified scheduler it's p2's time to get swapped out, but p1 is still being swapped out. The problem is (as others mentioned) the slow spindle rate of the disks. Some manufacturers have adopted disk stripping techniques to write bits out in parallel to several disks simultaneously, but we are reaching limitations in this. Solution? Partial swaping [or paging]. There are major I/O problems coming. The concept of staging memories and Extended Core as evidenced by older IBM and CDC architectures, and newer ex-Denelcor and Cray (SSD) ideas places too much memory management on users of large memory. > IBM has at least two announced models of CPU's available with 256M real, > though it's treated in a weird fashion. Not quite in the same league. The C-2 is 256 Mega WORDs, those IBMs are BYTES: they differ by a factor of 8. Practically an order of magnitude. As you pointed out in another article scale-up is a problem. > > >Third response: Decrease program startup? (Tentative.) I think this is valid, but many here at Ames won't agree. > there is never enough memory. RIGHT! > remember that a Cray-2 is meant to be used to run only a few programs > at a time. the available real memory per process is much higher > than for a general purpose computer system. the Cray is hardly > representative of the "typical" computer system. > > Herb Chong... The first statment above is not true inspite of the 1st argument regarding virtual memory I mentioned. That was just a sample case. Consider, as a Cray rep pointed out at CUG in Montreal, this is not a 256 MW machine (because of power 2 truncation), it closer to 268 MW (decimal): 12 mega words or 96 Megabytes of memory to support interactive work for how many users? Much larger and faster than any VAX. If we want to think typical, that's okay, but I think thinking like that will keep IBM behind Cray in performance (nothing personal). Would you submit your favorite card deck to an IBM PC to keep "thruput" high? ;-) [This later comment was an early IBM justification against interactive computating. I also once saw an ad by Univac again "user-friendly" computing for the same reasons.] From the Rock of Ages Home for Retired Hackers: --eugene miya NASA Ames Research Center {hplabs,ihnp4,dual,hao,decwrl,allegra}!ames!aurora!eugene emiya@ames-vmsb
john@datacube.UUCP (11/08/85)
Vertual memory or something like it will always be necessary.
Vertual memory is just a particular solution to the memory hierarchy
problem at a certian level. Memory hierarchys will always be with
us, why? Because for any given memory technology there always will
be a faster more expensive one, and a slower less expensive one. This
is despite the fact that rotating magnetic storage may become obsolete
because semiconductor memories become less expensive per bit and are
already known to be faster.
Vertual memory solves the memory hierarchy problem at the level
where we wish to have more in "core" for what ever reason, than we
have core. This will always be true, because of one of the fundamental
laws of computing is that any application or system will expand to
use all the availabel resources and then demand some more. Imagine
a 1K X 1K X1k array representing a cube of 3D image data, at low
resolution I might add. Suppose I wish to add a temporal dimension to
this, now prehaps 1K X 1K X 1K X1K in core would be adequate but I
seriously doubt it.
Vertual memory is just a way of dealing with the core to disk
transition in the memory hiearchy occuring at an inconvienent place.
Systems can be built that move this transition to a more convienent
place, for manny applications. However there always will be
applications where the active code size is greater than the "core"
size and so therefore vertual memory implemented by the operating
system and hardware, or VM implemented by the application in the
form of paging will be necessary.
Another thing to consider is the next higher break in the
memory hierarchy, that between cache and "main memory". Fundamentaly
it is very similar to that between main memory and disk, but nobody
complains about it because cache is seen as an improvement, and
because the bandwidth mismatch is much less than that between core
and disk.
The names of the levels of the hierarchy will change but the
functions will not.
John Bloomfield
these are opinions and may not be mine or any one else's