Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!usc!apple!voder!dtg.nsc.com!waggoner From: waggoner@dtg.nsc.com (Mark Waggoner) Newsgroups: comp.sys.amiga.tech Subject: Re: DMA in VM Message-ID: <101@dtg.nsc.com> Date: 1 Dec 89 19:48:02 GMT References: <14059@grebyn.com> <2054@atanasoff.cs.iastate.edu> <14060@grebyn.com> <4643@sugar.hackercorp.com> Reply-To: waggoner@dtg.UUCP (Mark Waggoner) Organization: National Semiconductor, Santa Clara Lines: 36 In article <4643@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <14060@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >> Laugh if you like. In VAX/VMS, every part of a process is virtual >> memory, including any IO buffering. The IO system takes care of ensuring >> that such pages are resident and locked for the duration of a DMA IO >> transfer. > >Too bad it doesn't go one step more and make the files *really* mapped, so >they "page" back into the real file they're supposed to come from. > >Really, I don't see the point of writing stuff to one part of the disk when >you're just going to have to read it in again and write it to another part >of the disk later on. > >This was a feature of Multics some, oh, 20 years ago now. ALL files were mapped >into memory... paged to and from the physical disk on demand. If you had a fast disk that you were using for your virtual memory swapping and a somewhat slower disk you were using for your main storage it would make sense to move it from the storage disk to the virtual memory disk. You might, for example, have a large optical WORM type drive with lots of data on it and a smaller, but faster hard drive that you used just for VM. You also wouldn't want to map the buffers for a floppy drive back on to the floppy that they came from. Stupid extra lines for rn. -- ,------------------------------------------------------------------. | Mark Waggoner (408) 721-6306 waggoner@dtg.nsc.com | `------------------------------------------------------------------'