mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) (04/08/91)
Given the virtual memory capacities of system 7.0, will there be any need to purchase additional RAM? If not, will it even be advantageous to have more RAM rather than less? ------------------------------------------------------------------------ maria i. lasaga department of psychology gilmer hall university of virginia charlottesville, va 22903 mil@virginia ------------------------------------------------------------------------
ds4a@dalton.acc.Virginia.EDU (Dale Southard) (04/10/91)
In article <1991Apr8.010338.14202@murdoch.acc.Virginia.EDU> mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) writes: > >Given the virtual memory capacities of system 7.0, will there be any >need to purchase additional RAM? If not, will it even be advantageous >to have more RAM rather than less? > How much real ram do you have? How much do you want? How much will you use? Seriously, the answer to your question is, what preformance is acceptable to you? Real ram is faster than virtual ram. I would not think that having 1meg real/13 meg virtual would be acceptable unless you never used more than one meg. Personal suggestion: install as much ram as you generally use in day-to-day work (it's cheap). Rely on virtual for anything over that. Remember that you will need a 68030 or a 68020 w/PMMU to use virtual mem. in system 7, as well as a compatable HD driver (what constitutes a "compatable driver" is a bit murky now -- I'm sure it will be figured out the week after 7 is released -- HEY! how come V-M won't work?!?!) --> --> Dale UVa (ds4a@virginia.edu)
ephraim@think.com (Ephraim Vishniac) (04/12/91)
In article <1991Apr9.220140.18228@murdoch.acc.Virginia.EDU> ds4a@dalton.acc.Virginia.EDU (Dale Southard) writes: >In article <1991Apr8.010338.14202@murdoch.acc.Virginia.EDU> mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) writes: >> >>Given the virtual memory capacities of system 7.0, will there be any >>need to purchase additional RAM? If not, will it even be advantageous >>to have more RAM rather than less? >How much real ram do you have? How much do you want? How much will you use? >Seriously, the answer to your question is, what preformance is acceptable >to you? Real ram is faster than virtual ram. I would not think that having >1meg real/13 meg virtual would be acceptable unless you never used more than >one meg. >Personal suggestion: install as much ram as you generally use in day-to-day >work (it's cheap). Rely on virtual for anything over that. Maybe a real example would be helpful. I ran my Mac II with VIRTUAL (the Connectix product) and 2M of physical memory for a long time. I was happy as long as the programs I ran were of reasonable size and I didn't switch between them terribly often. Then I tried to debug a large application using Think C's source-level debugger. At every step in the debugger, the application would swap in, execute one source-level instruction, and get swapped out in favor of the debugger. It was hideous. I upgraded to 5M of physical memory the next day. -- Ephraim Vishniac ephraim@think.com ThinkingCorp@applelink.apple.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142 One of the flaws in the anarchic bopper society was the ease with which such crazed rumors could spread.
ech@cbnewsk.att.com (ned.horvath) (04/12/91)
From article <1991Apr8.010338.14202@murdoch.acc.Virginia.EDU>, by mil@mendel.acc.Virginia.EDU (Maria I. Lasaga): > Given the virtual memory capacities of system 7.0, will there be any > need to purchase additional RAM? If not, will it even be advantageous > to have more RAM rather than less? You can never have enough RAM! Seriously, though, in the early days of VM (late 60's -- yes, I KNOW the Atlas was running in '57!) empirical studies gave a rule of thumb of about a factor of two between real and virtual memory; try to squeeze it more than that, and you begin to spend all your time in disk-wait. That is likely to be even MORE true for the graphics- intensive applications we run now than it was then. A bit more sophisticated notion is that of a working set, which is a fancy way of saying that a program needs to have rapid access to the data and code it's actively using in order to perform well. If real memory is less than the sum of the working sets for the active programs, you're going to see severe performance degradation. VM systems characteristically have a "knee" in the performance curve at that sum-of-working-sets point: add just one process, and the disklights go full on, and performance goes into the tank. Of course, your mileage may vary; if you run lots of applications that don't maintain open windows, and don't do a lot of processing in background, you may find that VM really helps a lot. Swapping in working sets is cheaper than launching the program. If you run with MPW running C++ makes and a terminal emulator doing up/downloads and the printmonitor punching away and the kids using your Mac as a server, all in the background, you may conclude that VM is a waste of time... =Ned Horvath=
jackb@MDI.COM (Jack Brindle) (04/12/91)
In article <1991Apr8.010338.14202@murdoch.acc.Virginia.EDU> mil@mendel.acc.Virginia.EDU (Maria I. Lasaga) writes: > >Given the virtual memory capacities of system 7.0, will there be any >need to purchase additional RAM? If not, will it even be advantageous >to have more RAM rather than less? I see several reasons to have large amounts of RAM in your Mac with sys 7. The first is that the sys 7 system heap is quite large (at least for B4). Mine currently runs about 1.5 Megs. I'm not sure why it is so large, but I do have sharing turned on (but not VM). Sharing seems to account for only about 180K or so, though. The finder grabs another 340K. (Side question - has anyone figured out why the system heap is so large?) This leaves a small amount of memory available for applications in a 2 Meg machine (Mine has 5 MB - it still feels a bit cramped). The second reason is that VM eats up disk space. If you have 14 Megs of VM, then you will use up 14 Megs of disk space. That leave only 26 megs of storage on a 40 MB hard disk. This is the biggest reason I don't run VM - I need the extra storage. Lastly, you should expect some applications to break under VM. If the applications use a Vertical timing interval task or any other task that runs at interrupt time, there could be a quick debugger exit (AKA BOMB). The reason is that if the task is swapped to disk when an interrupt that triggers the task occurs, the machine will vector to where it thought the task was (but no longer is). System 7 has functions to lock down the tasks so they won't be swapped. Of course, pre Sys-7 applications don't know about the functions, so they don't use them. I sure hope the folks in Redmond have their (now very good) tech support staff prepped for this one :-). My question actually becomes one of whether VM is all that useful to run. It's quite possible the Macintosh Plus/Classic folks will have nothing to miss with this feature! - Jack B. amateur radio: wa4fib/7
gillies@m.cs.uiuc.edu (Don Gillies) (04/12/91)
In my limited experience on a Xerox 8010, I concluded that virtual memory would give you about twice as much "usable" memory as physical memory. So if you have 5Mb of DRAM, 10Mb of virtual memory is a reasonable limit. With 2Mb of DRAM, 4Mb was a reasonable limit for virtual memory. Beyond that limit, even if the code has been repackaged to minimize working sets (i.e. to minimize paging), the machine would still start to thrash badly. I suspect the Mac OS is very poorly structured for virtual memory, so your mileage may vary. Don Gillies | University of Illinois at Urbana-Champaign gillies@cs.uiuc.edu | Digital Computer Lab, 1304 W. Springfield, Urbana IL ---------------------+------------------------------------------------------ "WAR! UGH! ... What is it GOOD FOR? ABSOLUTELY NOTHING!" - the song "WAR" by Edwin Starr, circa 1971 --
amanda@visix.com (Amanda Walker) (04/13/91)
In article <1991Apr11.193950.7332@cbnewsk.att.com> ech@cbnewsk.att.com (ned.horvath) writes: gave a rule of thumb of about a factor of two between real and virtual memory; try to squeeze it more than that, and you begin to spend all your time in disk-wait. This rule of thumb seems about right for System 7.0, as well. 10M virtual running in 5MB physical works very nicely. More than that begins to bog down some. I'd also recommend running at least 4MB physical, or you're going to be spending all your time swapping your system heap back in... -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- X Windows: It could be worse, but it'll take time...
Greg@AppleLink.Apple.Com (Greg Marriott) (04/14/91)
In article <1991Apr12.201532.18426@visix.com>, amanda@visix.com (Amanda Walker) writes: > I'd also recommend running at least 4MB physical, or you're > going to be spending all your time swapping your system heap back in... Nope. The system heap is held in physical RAM and never paged to disk. Greg Marriott Blue Meanie Apple Computer, Inc.
amanda@visix.com (Amanda Walker) (04/16/91)
In article <13051@goofy.Apple.COM> Greg@AppleLink.Apple.Com (Greg Marriott) writes: Nope. The system heap is held in physical RAM and never paged to disk. Yow. Yet more reason to have at least 4MB of physical memory... -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- "I can only assume this is not the first-class compartment." --The Hitchhiker's Guide to the Galaxy
kenh@eclectic.COM (Ken Hancock) (04/20/91)
In article <1991Apr12.201532.18426@visix.com> amanda@visix.com (Amanda Walker) writes: >In article <1991Apr11.193950.7332@cbnewsk.att.com> ech@cbnewsk.att.com >(ned.horvath) writes: >This rule of thumb seems about right for System 7.0, as well. 10M virtual >running in 5MB physical works very nicely. More than that begins to bog >down some. I'd also recommend running at least 4MB physical, or you're >going to be spending all your time swapping your system heap back in... Except, of course, that the system heap is NEVER swapped out under System 7.0. On my 8 meg IIci, 2.6 megs is already held in memory as the system heap. Ken as part of the System heap. *bleh*` -- Ken Hancock | INTERNET: kenh@eclectic.com Isle Systems | Compuserve: >INTERNET: kenh@eclectic.com Macintosh Consulting | AOL: KHancock | Disclaimer: My opinions are mine, | your opinions are yours. Simple, isn't it?
dawg6844@uxa.cso.uiuc.edu (Race Bannon) (04/22/91)
kenh@eclectic.COM (Ken Hancock) writes: >Except, of course, that the system heap is NEVER swapped out under >System 7.0. On my 8 meg IIci, 2.6 megs is already held in memory >as the system heap. >Ken 2.6 Megs?!?! How many blasted inits (excuse me, extensions) are you running, for godsake? I also have an 8M ci, and my sys heap is only 1.8M. -- _______________________________________________________________________________ Dan Walkowski | To understand recursion, Univ. of Illinois, Dept. of Comp. Sci. | you must first understand recursion. walkowsk@cs.uiuc.edu |
hasses@prism.cs.orst.edu (Stephen Haase) (04/22/91)
One VERY annoying thing I noticed with system 7's virtual memory was that x amount of HD space does not equal x amount of extra RAM. I got 7.0fc2 going and then tried to add 3 megs of RAM to my 5 physical RAM. It worked all right, but it took 8 megs of HD space to give me those extra 3 megs. Needless to say, I removed it quickly since I only have 9 megs free anyways. Steve hasses@prism.cs.orst.edu
rhumphre@silver.ucs.indiana.edu (Robert P. Humphrey) (04/22/91)
In article <1991Apr22.034204.16962@ux1.cso.uiuc.edu> dawg6844@uxa.cso.uiuc.edu (Race Bannon) writes: >kenh@eclectic.COM (Ken Hancock) writes: > > >>Except, of course, that the system heap is NEVER swapped out under >>System 7.0. On my 8 meg IIci, 2.6 megs is already held in memory >>as the system heap. > >2.6 Megs?!?! >How many blasted inits (excuse me, extensions) are you running, for godsake? >I also have an 8M ci, and my sys heap is only 1.8M. >-- >Dan Walkowski | To understand recursion, Of course, you guys (I assume) are running Beta versions, which are chock full of debugging code. I'm hoping that the release will be less than that. (I've only got 4Meg guys, give me a break. Guys? GUYS?) Bob -- ******************************************************************************* Robert Humphrey, "It's easy to grin when your ship comes in, Gentleman Scholar And you've got the stock market beat; But the man worthwhile, Is the man who can smile, rhumphre@ucs.indiana.edu When his shorts are too tight in the seat." -Ted Knight, Caddyshack *******************************************************************************
dawg6844@uxa.cso.uiuc.edu (Race Bannon) (04/22/91)
rhumphre@silver.ucs.indiana.edu (Robert P. Humphrey) writes: > Of course, you guys (I assume) are running Beta versions, >which are chock full of debugging code. I'm hoping that the release >will be less than that. (I've only got 4Meg guys, give me a break. >Guys? GUYS?) > Bob ] No, I'm running f3, a final release candidate. However, I have had the heap as small as 1.2M with no inits. (Believe it or not, even 1.8M is smaller than I used to run under 6.0.x. I used to be over 2M. The decrease is because nearly ALL the functionality of the inits I used to run has been incorporated into 7) -- _______________________________________________________________________________ Dan Walkowski | To understand recursion, Univ. of Illinois, Dept. of Comp. Sci. | you must first understand recursion. walkowsk@cs.uiuc.edu |
breidenb@Informatik.TU-Muenchen.DE (Oliver Breidenbach) (04/22/91)
In article <1991Apr22.042204.1291@lynx.CS.ORST.EDU> hasses@prism.cs.orst.edu (Stephen Haase) writes: >One VERY annoying thing I noticed with system 7's virtual memory was that x >amount of HD space does not equal x amount of extra RAM. I got 7.0fc2 going and >then tried to add 3 megs of RAM to my 5 physical RAM. It worked all right, but >it took 8 megs of HD space to give me those extra 3 megs. Needless to say, I >removed it quickly since I only have 9 megs free anyways. that is what "virtual memory" is. The physical space is mapped to a logical one. That implies that you need to have the whole physical space available somewhere in order not to loose information. I guess that Apple has choosen to have all available space on the disk in order to reduce "write-back" operations. They don't have to write back space that hasn't changed since it was loaded into ram, like most parts of the applications code. However, it's just a guess. Oliver.
aland@chaos.cs.brandeis.edu (Alan D.) (04/24/91)
In article <1991Apr22.042204.1291@lynx.CS.ORST.EDU> hasses@prism.cs.orst.edu (Stephen Haase) writes:
One VERY annoying thing I noticed with system 7's virtual memory was that x
amount of HD space does not equal x amount of extra RAM. I got 7.0fc2 going and
then tried to add 3 megs of RAM to my 5 physical RAM. It worked all right, but
it took 8 megs of HD space to give me those extra 3 megs. Needless to say, I
removed it quickly since I only have 9 megs free anyways.
Steve
hasses@prism.cs.orst.edu
Very annoying, but quite necessary. You need to have some place to
swap OUT the memory you're replacing with the new memory... And
therefore you need as much free space on the HD as you want in virtual
memory, notwithstanding the amount of actual RAM you have.
-=Alan
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alan D. Danziger, | 753 South St,Waltham MA 02154 | "Just sitting
aland@chaos.cs.brandeis.edu | MB 3130 / Brandeis University | here, on the
(617) 894-6859 or 647-3720 | PO Box 9110 Waltham MA 02254 | Group W Bench"
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=bruner@sp15.csrd.uiuc.edu (John Bruner) (04/26/91)
In article <ALAND.91Apr24115728@chaos.cs.brandeis.edu> aland@chaos.cs.brandeis.edu (Alan D.) writes: > In article <1991Apr22.042204.1291@lynx.CS.ORST.EDU> hasses@prism.cs.orst.edu (Stephen Haase) writes: > >> One VERY annoying thing I noticed with system 7's virtual memory was that x >> amount of HD space does not equal x amount of extra RAM.... > > Very annoying, but quite necessary. You need to have some place to > swap OUT the memory you're replacing with the new memory... And > therefore you need as much free space on the HD as you want in virtual > memory, notwithstanding the amount of actual RAM you have. Sadly, it isn't necessary; rather, it simply is easier to implement virtual memory by associating a fixed secondary storage address for each virtual page. Dynamically assigning secondary storage addresses as pages are paged out does incur some additional space overhead, but the space savings are worth the extra bookkeeping. Many BSD-derived UNIX implementations take this approach, but there are certainly implementations that do not. It is too bad that Apple did. It does, however, encourage users to buy more disc storage. -- John Bruner Center for Supercomputing R&D, University of Illinois bruner@csrd.uiuc.edu (217) 244-4476
ech@cbnewsk.att.com (ned.horvath) (04/26/91)
In article <1991Apr22.042204.1291@lynx.CS.ORST.EDU> hasses@prism.cs.orst.edu (Stephen Haase) writes: >One VERY annoying thing I noticed with system 7's virtual memory was that x >amount of HD space does not equal x amount of extra RAM. I got 7.0fc2 going and >then tried to add 3 megs of RAM to my 5 physical RAM. It worked all right, but >it took 8 megs of HD space to give me those extra 3 megs. Needless to say, I >removed it quickly since I only have 9 megs free anyways. From article <ALAND.91Apr24115728@chaos.cs.brandeis.edu>, by aland@chaos.cs.brandeis.edu (Alan D.): > Very annoying, but quite necessary. You need to have some place to > swap OUT the memory you're replacing with the new memory... And > therefore you need as much free space on the HD as you want in virtual > memory, notwithstanding the amount of actual RAM you have. "Convenient for the Systems Programmer," perhaps. Necessary, no. The VM implementation has to track which pages are in physical memory in any case. But if you add a table of ALL pages, with either a RAM address OR a disk address for each page, then you need only allocate disk space to accommodate the difference between virtual and real, plus one "free" page to swap out to. Yes, the table itself occupies "real" RAM. But assuming a reasonable page size, say 4K or larger, the table size is negligible. You must reserve one free page frame in memory. On a fault, seek to the needed page, swap it into the reserved frame, then swap the unneeded page to the same disk page frame you just read from. This has the nice performance advantage that the paging device only seeks once per page fault. I think it's important to notice that this is the first VM implementation for the Mac, not the last. A number of us are upset that VM provides no additional protection. The official answer was that it would break "certain programs," i.e. SADE. I think Apple missed an opportunity to do it "right," but the opportunity is scarcely gone forever. It's also important to notice that the emphasis in System 7.0 has been to enable better performance by applications, working in concert, by providing a better application framework. The OS is badly in need of an overhaul, but it's a lower priority for Apple. And rightly so. I only speak for me. =Ned Horvath= ehorvath@attmail.com
kchang@ncsa.uiuc.edu (Kenneth Chang) (04/26/91)
In article <BRUNER.91Apr25130920@sp15.csrd.uiuc.edu> bruner@sp15.csrd.uiuc.edu (John Bruner) writes: >> In article <1991Apr22.042204.1291@lynx.CS.ORST.EDU> hasses@prism.cs.orst.edu (Stephen Haase) writes: >> >>> One VERY annoying thing I noticed with system 7's virtual memory was that x >>> amount of HD space does not equal x amount of extra RAM.... >> >Sadly, it isn't necessary; rather, it simply is easier to implement >virtual memory by associating a fixed secondary storage address for >each virtual page. Dynamically assigning secondary storage addresses >as pages are paged out does incur some additional space overhead, but >the space savings are worth the extra bookkeeping. > There's a better reason that "Apple was lazy." To quote from the manual for Connectix's Virtual (which implements virtual memory in a similar fashion): "Performance. When swapping a page in memory that has not been modified, we can speed up the page swap time by a factor of two if we can count on there still being a disk image of the unmodified page. This requires that we be able to store the image of all pages in the virtual memory space, regardless of whether it is RAM." -- Kenneth Chang | National Center for Supercomputing Applications kchang@ncsa.uiuc.edu | Consulting Office/(217)244-1144 ----------------------------------------------------------------------------- "Everything's entertainment in America eventually" -- Tracy Ullman
philip@pescadero.stanford.edu (Philip Machanick) (04/26/91)
In article <1991Apr25.190940.15729@cbnewsk.att.com> ech@cbnewsk.att.com (ned.horvath) writes: >In article <1991Apr22.042204.1291@lynx.CS.ORST.EDU> hasses@prism.cs.orst.edu (Stephen Haase) writes: > >>One VERY annoying thing I noticed with system 7's virtual memory was that x >>amount of HD space does not equal x amount of extra RAM. I got 7.0fc2 going and >>then tried to add 3 megs of RAM to my 5 physical RAM. It worked all right, but >>it took 8 megs of HD space to give me those extra 3 megs. Needless to say, I >>removed it quickly since I only have 9 megs free anyways. > >From article <ALAND.91Apr24115728@chaos.cs.brandeis.edu>, by aland@chaos.cs.brandeis.edu (Alan D.): > >> Very annoying, but quite necessary. You need to have some place to >> swap OUT the memory you're replacing with the new memory... And >> therefore you need as much free space on the HD as you want in virtual >> memory, notwithstanding the amount of actual RAM you have. > >"Convenient for the Systems Programmer," perhaps. Necessary, no. The VM >implementation has to track which pages are in physical memory in any case. >But if you add a table of ALL pages, with either a RAM address OR a disk >address for each page, then you need only allocate disk space to >accommodate the difference between virtual and real, plus one "free" page >to swap out to. [...] There are other reasons to keep the whole of VM on disk. If you get a total system crash, it's nice to be able to see a reasonably recent snapshot of system state. If you want to migrate a process on a distributed architecture, it's relatively easy. >I think it's important to notice that this is the first VM implementation >for the Mac, not the last. A number of us are upset that VM provides no >additional protection. The official answer was that it would break "certain >programs," i.e. SADE. I think Apple missed an opportunity to do it "right," >but the opportunity is scarcely gone forever. > I agree with you on protection, but maybe there were good reasons for requiring that the entire address space be on disk. Who knows - maybe Apple is planning ahead for the kind of major changes we'd like to see. Philip Machanick
lemke@radius.com (Steve Lemke) (04/26/91)
philip@pescadero.stanford.edu (Philip Machanick) writes: >There are other reasons to keep the whole of VM on disk. If you get a total ^^^^^^^^^^^^^^^^^^ >system crash, it's nice to be able to see a reasonably recent snapshot ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >of system state. ^^^^^^^^^^^^^^^^ This is a nice idea, and would be even nicer if there were some utility that could crawl through the VM file and actually tell you something about what happened. As it is now, I would imagine when you reboot you'll lose all that useful information, and even if you boot from another disk, there really aren't any tools for dissecting the remains of your preserved VM file. -- ----- Steve Lemke, KC6QDT - Software Engineering, Radius Inc., San Jose ----- ----- Reply to: lemke@radius.com -- U.C. Santa Barbara ECE Class of '89 ----- ----- "I'm not a UNIX wizard, but I play the Postmaster at radius.com." -----