Re: A simple question about DMA, please help me.

In article <1184772977.582865.311290@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
spamtrap@xxxxxxxxxx says...
Many relevant books tell me that when DMA is working, the data bus is
held by the DMA controller and the CPU is set idle until this transfer
completes.

However, if we start a time-consuming DMA operation, say, copying a
large file, we can still do many other things at the same time, say,
playing a song or drawing a picture. In this situation, it is evident
that the CPU are not idle, that is, the CPU can still access the
memory to fetch instructions while the DMA transfer is continuing.
What text books tell me differs from what I experience, who can tell
me what the cause is?

[ warning: long post ]

Copying a large file isn't a DMA operation, at least in a typical modern
computer. In fact, a typical modern computer (i.e. anything with a PCI
bus) doesn't _really_ do DMA at all!

The ISA bus on the original PC, (and in modified form in the AT) had
separate bit lines to signify what kind of transaction was going to take
place in a given cycle -- a memory read, memory write, I/O read or I/O
write. In a normal situation, only one of these lines was asserted
during a given bus cycle. The DMA controller, however, would assert two
of them -- the I/O read and memory write or the memory read and I/O
write. It would then place addresses on the bus, and you'd get (in a
_single_ bus transaction) a transfer from memory to an output port, or a
transfer from an input port to memory (since it only had a chance to
give one address, it could NOT do a memory-to-memory transfer).

The PCI bus changed that -- it eliminated the separate lines for each
type of transaction, and instead encodes the transaction type. This
means the "trick" that allowed DMA to work just doesn't work over PCI.

On PCI, you mostly have bus-mastering controllers -- each PCI device can
do its own reading or writing independently. They negotiate for control
of the bus, and keep control of it for some length of type, then release
it. A few controllers are slave-only, which means they can be targets of
transactions, but can't initiate transactions themselves. Either way,
however, you don't have a DMA transaction.

On a modern machine you also have a _huge_ disparity between the speeds
of different busses. For example, the normal PCI bus is 32 bits wide and
runs at 33 MHz. For example, a reasonably high-end machine might have
two memory channels, each 64 bits wide, and each running at a data
transfer rate of 800 MHz.

To make up that disaparity, the north bridge normally has fairly good-
sized buffers. When a PCI device requests some data from memory, the
north bridge reads the data from memory at the full memory speed, and
stores the result in its own buffers. The data is then transferred to
the PCI device at the (much) lower PCI speed -- but as soon as the data
has been transferred from the memory to the north bridge, the CPU is
free to access the memory again -- and will probably do so _many_ times
before the data finishes transferring over the PCI bus.

To put things in perspective, consider transferring 1 kilobyte over a
PCI bus. That's 256 32-bit words at 33 MHz, giving about 7.76
microseconds. For a 1 GHz P III CPU, that's enough time to execute
something like ten thousand instructions. For a current CPU (e.g. dual
core, @ ~3 GHz), figure something like fifty to sixty thousand
instructions.

Of course, that's figuring in terms of a PCI device that can handle
transfers at full PCI speed. A transfer to/from floppy disk (for one
obvious example) would be drastically worse. In theory, you could make
up for it (usually) by having a big enough cache on the CPU, but you'd
need a huge cache to do the job for the duration of a floppy disk
transfer -- it's much cheaper to buffer the data for the floppy disk
instead (and as a bonus, that memory doesn't need to be nearly as fast).

--
Later,
Jerry.

The universe is a figment of its own imagination.

.

Relevant Pages

  • Re: 21st Century ISA goals?
    ... With a 3.0 Ghz processor, a microsecond is 3000 clock cycles, with something like the Core 2 or Athlon 64, that is potential 12000 instructions that are not executed because your waiting for a PCI read to complete. ... Also note that any memory traffic that the PCI devices are causing is bandwidth the CPUcan't use (as Nick has pointed out, even with a 1333 Mhz bus bandwidth is a limitation once you get to 4 CPUs or more). ... I do a lot of programming at hardware level, but looking at your post re pci transactions again, the thing that stands out most of all is the amount of cpu involved low level itsy traffic across the bus, ie:, where the device can't even get it's i/o descriptor / control block until cache has been flushed back to memory. ...
    (comp.arch)
  • PROBLEM: DMA over CPU" memory leak in Kernel 2.6.8.1
    ... "DMA over CPU" memory leak if I burn Audio-CDs ... d0000000-dfffffff: PCI Bus #01 ...
    (Linux-Kernel)
  • Re: Trying to DMA data from PCI bus to IDE
    ... >to handle DMA transfers across the PCI bus to the rest of the PC104 ... >memory, and then use the regular Linux functions to write it to the ...
    (comp.os.linux.development.system)
  • Re: Volatile variables
    ... I/O methods ("DMA" and the like) that completely bypass the CPU. ... then DMA bypasses the on-chip cache. ... memory. ...
    (comp.lang.c)
  • Re: High-performance IO
    ... Any well implemented PCI DMA these days will both support over 4GB ... but discontinuities limit the length of the DMA transfers. ... If the length of a contiguous memory block is equal to the size ... I know that AWE can give the programmer a way to use ...
    (microsoft.public.win32.programmer.kernel)