Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!iuvax!purdue!haven!grebyn!ckp
From: ckp@grebyn.com (Checkpoint Technologies)
Newsgroups: comp.sys.amiga.tech
Subject: Re: DMA in VM
Message-ID: <14060@grebyn.com>
Date: 30 Nov 89 17:31:37 GMT
References: <14059@grebyn.com> <2054@atanasoff.cs.iastate.edu>
Reply-To: ckp@grebyn.UUCP (Checkpoint Technologies)
Organization: Grebyn Timesharing, Vienna, VA, USA
Lines: 23

In article <2054@atanasoff.cs.iastate.edu> jwright@atanasoff.cs.iastate.edu (Jim Wright) writes:
>ckp@grebyn.UUCP (Checkpoint Technologies) writes:
>| 	Oh, and it would be a dirty shame if programs weren't able to
>| allocate virtual memory for their disk buffers, IMHO. It would make
>| virtual memory less useful.
>
>This is as good as the one posted a while ago...
>
>	"I so glad I bought the virtual memory addon for my
>	Mac.  Now I'm gonna make a *really* big RAM disk with it."
>
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.

Consider this: An application reads a project into memory, works on it
for a while, then writes it back out. The reading and writing part would
be best served by large IO buffers, to take best advantage of the fast
file system. If allocated in virtual memory, these buffers can be paged
out when not in use, to allow best use of physical memory for the
project at hand. And further, when resident, they need not be physically
contiguous, which makes most efficient use of physical memory.