Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!grebyn!ckp
From: ckp@grebyn.com (Checkpoint Technologies)
Newsgroups: comp.sys.amiga.tech
Subject: Re: DMA in VM
Message-ID: <14064@grebyn.com>
Date: 1 Dec 89 16:36:13 GMT
References: <14059@grebyn.com> <8778@cbmvax.UUCP>
Reply-To: ckp@grebyn.UUCP (Checkpoint Technologies)
Organization: Grebyn Timesharing, Vienna, VA, USA
Lines: 28

In article <8778@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
>
>There's an awful good chance both kinds of controllers would need revised
>device drivers.  The DMA controllers certainly will.
>
	Surely all the current hard disk controllers can
be made to support DMA with the right drivers. What I mean is that DMA
won't be as valuable.

>What the DMA _driver_ has to do is call the 
>Virtual2Physical() system call, or whatever they use for this kind of
>support, and get back the physical page(s) that correspond to that
>one virtual block.  Then the _driver_ sets up the controller to DMA
>directly into each physical block.  Obviously if there are several
>small blocks, this will take a little longer than one big block, but
>it's no tragedy; it'll still be fast.

	One of the better ways to slow down a transfer, is to break a
large transfer into a buncha smaller ones; then you have the host CPU
racing to keep up with the spin of the disk drive. Likely you'll have to
resort to interleaving greater than 1:1.

	As long as you can be sure that a single physical disk sector
will always be within a physical memory page, then one good translated
DMA will do fine. More likely, however, is that some of the disk sectors
would span the gap between physical memory pages. Then, without hardware
to handle a discontiguous DMA transfer, you'll have to DMA into a
different contiguous memory area and copy the results.