ralph@computing-maths.cardiff.ac.uk (Ralph Martin) (05/17/89)
Will the virtual memory require a separate partition on the hard disk, or will there be a swap file? If the former, it seems like an awful lot of people will need to reformat their disks. Furthermore, what about people with 3rd party hard disks? If anyone could shed some light on this, I'd be interested.
goldman@apple.com (Phil Goldman) (05/20/89)
In article <758@cf-cm.UUCP> ralph@computing-maths.cardiff.ac.uk (Ralph Martin) writes: > Will the virtual memory require a separate partition on the hard disk, > or will there be a swap file? There will be a backing store file that can be put on any local disk (if it has enough room). It will be a simple HFS file, and need not be contiguous -- there will be no need to re-format disks. -Phil Goldman Apple Computer
ngg@bridge2.ESD.3Com.COM (Norman Goodger) (05/26/89)
In article ralph@computing-maths.cardiff.ac.uk (Ralph Martin) writes: >Will the virtual memory require a separate partition on the hard disk, >or will there be a swap file? If the former, it seems like an awful lot >of people will need to reformat their disks. Furthermore, what about >people with 3rd party hard disks? >If anyone could shed some light on this, I'd be interested. If the Apple Virtual memory implemenation works like Connectix's, you will not have to do anything other to insure that you have adequate "contigious" space on your HD. Which at most would require that you run a de-fragmenting program on your HD before running Virtual. Connectix uses a file equal the amount of ram being used, ie 8 megs. This file stores the memory data to be swapped in and out. I just hope that Apple's implementation is configurable in some way, so you can set the amount of Virtual memory you want to use (or can afford on your HD)...
jordan@Apple.COM (Jordan Mattson) (05/26/89)
Actually, you don't have to have contiguious free disk space. It will be able to use discontiguious disk space. Jordan Mattson UUCP: jordan@apple.apple.com Apple Computer, Inc. CSNET: jordan@apple.CSNET Development Tools Product Management AppleLink: Mattson1 20525 Mariani Avenue, MS 27S Cupertino, CA 95014 408-974-4601 "Joy is the serious business of heaven." C.S. Lewis
mha@batcomputer.tn.cornell.edu (Mark H. Anbinder) (05/27/89)
In article <31723@apple.Apple.COM> jordan@Apple.COM (Jordan Mattson) writes: > > Actually, you don't have to have contiguious free disk space. It will >be able to use discontiguious disk space. Does Apple's VM at least know how to take advantage of contiguous space, and will Apple recommend that users provide contiguous space? Having a contiguous chunk of space for a virtual memory system to play in speeds it up enormously. When the Virtual program from Connectix creates its virtual memory storage on disk, it grabs eight megs of contiguous space and KEEPS it. I hope Apple's will do the same. -- Mark H. Anbinder ** MHA@TCGould.tn.cornell.edu NG33 MVR Hall, Media Services Dept. ** THCY@CRNLVAX5.BITNET Cornell University H: (607) 257-7587 ******** Ithaca, NY 14853 W: (607) 255-1566 ******* "It's not safe out here." Q
goldman@apple.com (Phil Goldman) (05/27/89)
In article <8054@batcomputer.tn.cornell.edu> mha@batcomputer.tn.cornell.edu (Mark H. Anbinder) writes: > Does Apple's VM at least know how to take advantage of contiguous space, > and will Apple recommend that users provide contiguous space? Having a > contiguous chunk of space for a virtual memory system to play in speeds > it up enormously. When the Virtual program from Connectix creates its > virtual memory storage on disk, it grabs eight megs of contiguous space > and KEEPS it. I hope Apple's will do the same. Using contiguous disk space will not speed up paging time in most cases, as long as the file is not *seriously* fragmented (which is rare unless the disk is very close to full). The odds of a particular page lying in multiple file extents is very low (or non-existent if the page size is at least as small as the min extent size). Also, due to locality pages that need to be read in should be in the same extent. Finally, when the paging gets hot and heavy pages will be reclaimed and often written out to an entirely different part of the file, so big seeks will happen anyway. Of course, most of these arguments depend on the fact that the VM backing store file is a sizeable chunk of the entire disk. Otherwise, the disk seeks may become very costly if the extents are physically far apart. All this said, space will be allocated contiguously if at all possible, probably because it's the easiest way to implement it. The file will not need to be created each time the machine boots either. Also, you don't have to reformat your disk to get it. -Phil Goldman Apple Computer
paul@taniwha.UUCP (Paul Campbell) (05/31/89)
In article <2108@internal.Apple.COM> goldman@apple.com (Phil Goldman) writes: >In article <8054@batcomputer.tn.cornell.edu> >mha@batcomputer.tn.cornell.edu (Mark H. Anbinder) writes: >> Does Apple's VM at least know how to take advantage of contiguous space, >> and will Apple recommend that users provide contiguous space? Having a > >Using contiguous disk space will not speed up paging time in most cases, >as long as the file is not *seriously* fragmented (which is rare unless >the disk is very close to full). The odds of a particular page lying in The need for paging files/partitions to be contiguous is an idea which has hung around from the days of SWAPPING systems (note - many unix systems still page and swap - when things get tight whole processes are swapped out and taken out of contention for scheduling - this doen't make as much sense in the Mac environment where processes must remain around to respond to update events [BTW it was great to finally hear an Apple speaker use the word 'process' at the developer's conference]). It doesn't make much sense to require a paging file to be contiguous provided individual pages are contiguous on disk (in 4k chunks). What might make more sense are paging policies that place pages near the paged application's code and/or data files on disk, or near the last block read/written to/from the disk (ie near where the heads are now). In many ways the concept of putting the paging file inside the file system is better than the unix way of putting it in a different partition on the same disk (less head movement). On a two disk system it makes more sense to put the paging file on a different disk (esp. if you have a real async SCSI manager). Paul -- Paul Campbell Taniwha Systems Design UUCP: ..!mtxinu!taniwha!paul Oakland CA AppleLink: D3213 Achtung! Ve are from ze Interface Police! Ve vant to look und feel!
ts@cup.portal.com (Tim W Smith) (06/01/89)
When we were developing our 68012 based VM system at Callan, the first version just used the file system for paging. Process nnnn would page to/from the file /pages/nnnn. Eventually someone got me to admit that I did it this way because I was too lazy to write code to manage pages on the swap space. By that time I had a fancy memory allocation manager that was easy to use to manage disk blocks too, and so the paging got changed to use /dev/swap. I kind of like paging to the file system. It has a big advantage in that you don't end up having to statically allocate a big chunk of disk to handle paging. On the other hand, the performance is not going to be as good as going to a raw disk. I never got around to comparing the performance of the two methods, being distracted by Callan going under and all that. Tim Smith