🚀 go-pugleaf

in article <14064@grebyn.com>, ckp@grebyn.com (Checkpoint Technologies) says:

> 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.

Huh?  DMA is defined by the controller's hardware.  If that hardware
doesn't support DMA, no software in the world is going to make it do
so.  Period.

There are certain situations where DMA may not be as valuable.  With the
current system and certain accelerator boards, 32 bit memory isn't 
accessable by the expansion bus DMA (the CSA boards are an example --
they locate their 32 bit memory outside of the controllers' address
space).  In such a case, a non-DMA controller may very well be more
efficient.  Which is why Commodore-Amiga accelerator boards support
DMA into their 32 bit memory.

> 	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.

With virtual memory, you certainly can't guarantee contiguous buffer 
memory.  And with current alignment restrictions, you can't guarantee 
that blocks line up with physical pages in all cases.  Though in reality, 
you probably can, since it's the filesystem that makes most of the 
allocations for you, and it can certainly know about virtual memory 
and page alignments without any applications having to know.  If you're
loading programs across page boundaries, you're always going to be
slowing things down, since that'll increase paging activity considerably.
A slight slowing of DMA at that point will be the least of your worries
(MMU pages are likely to be 4k or 8k in size, vs. the 512 bytes of a 
disk blocks, and it's unlikely that memory will be so fragmented that
you'd often get disk pages unevenly crossing MMU page groups, even with
the current allocation scheme).

-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough