1
$\begingroup$

I recently discussed DMA and non-DMA with my OS professor. Here is my current understanding:

  • disk controller has its own CPU, maybe own ISA, tiny program that simply handles reading from the disk (firmware)
  • it is sort of "client-server" in that the main CPUs are the clients and the disk controller is the server, handling the request
  • disk controller with capability to put disk data directly into DRAM is called DMA controller

My question: why aren't all disk controllers DMA?

  • professor says: increase in complexity, synchronization and message passing problems
  • I say: it doesn't make sense and seems more complex to send to my CPU to send to memory instead of handling it itself and sending an interrupt when its done, especially if the amount of data is large and the data is buffered in registers (since the cache is controlled by the hardware and the programmer is meant to be oblivious to it)

What am I missing here?

Improve this question
$\endgroup$
2
  • $\begingroup$ In what way would that be "more complex" ? $\endgroup$
    – Yves Daoust
    May 7 at 12:40
  • $\begingroup$ things might have changed, but the DMA controller might be outside the HD and allow read/writes between the HD and RAM without the CPU intervention. The storage can be 'passive' in the sense it does not need to know whether it is read by the CPU or the DMA controller $\endgroup$
    – Ran G.
    May 7 at 17:02

1 Answer 1

Reset to default
0
$\begingroup$

On most modern systems, peripheral devices do not speak or control DMA directly. Rather, they communicate over a bus protocol (e.g. SCSI or ATA-over-PCI in the case of storage devices), and a special piece of hardware manages both the bus and the mechanics of DMA.

On PC hardware, this is known as the HBA (Host Bus Adapter), also known as AHCI controller (Advanced Host Controller Interface). This also handles things like device discovery and enumeration, so the OS can work out what devices are attached. I'm just going to use the term "host adapter".

The short answer as to why disk controllers don't write directly to RAM is that if you did it that way, every disk controller would have to be designed with every kind of CPU bus in mind.

I'm going to give two examples of why this would be an extremely complicated solution.

First example: cache coherency. When a DMA transfer occurs to some location in memory, you somehow need to ensure that any copies of that memory that are in some CPU's cache are invalidated. So in this scenario, every disk controller would have to be aware of every kind of CPU's cache coherence protocol.

Second example: interrupt delivery. When a DMA transfer completes, the CPU needs to receive an interrupt so that it knows that it is complete. Wait, did I say "the CPU"? I meant "a CPU". In a multiprocessing system, the OS decides which CPU receives which interrupts from which devices. So every disk controller would need to know about multi-CPU topologies as well.

On top of all this, DMA is a much more general concept than it used to be. Many modern host adapters can perform scatter/gather I/O, memory-to-memory copies (especially useful on NUMA architectures), and even device-to-device transfers. That last one is used in high-performance computing for low-latency network storage; some DMA controllers can burst data directly from a disk to a network card without passing through RAM or the CPU.

One last thing worth noting is that computers typically boot from disks, and having a simple non-DMA method for transferring data from disk to RAM, even if it uses CPU resources to do so, tends to be kinder on firmware and boot loaders.

Improve this answer
$\endgroup$
2
  • $\begingroup$ So are DMA done with specific instructions then? $\endgroup$
    – user129393192
    Jun 13 at 5:11
  • $\begingroup$ The host controller is a peripheral. The host CPU can communicate with that peripheral using memory-mapped I/O, or some other facility if available (e.g. port I/O on x86-like hardware). $\endgroup$
    – Pseudonym ♦
    Jun 13 at 7:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.