Direct memory access 2026-10-13
Direct memory access transfers data between a device and computer memory without the CPU executing a copy instruction for each item. The CPU still sets up the operation and observes completion. DMA answers who moves the data; an interrupt answers how a need for attention is announced. A DMA transfer can therefore finish with interrupt-driven input-output or with polled input-output. [ref]
https://pages.cs.wisc.edu/~remzi/OSTEP/file-devices.pdf. Arpaci-Dusseau and Arpaci-Dusseau, OSTEP chapter 36, section 36.5: DMA
For a toy receive operation, the CPU arranges a four-byte DMA buffer and tells the device its DMA address, length and direction. The device writes the bytes
A, B, C, D into that DMA buffer. After completion and any required DMA buffer synchronization, the CPU can read those four bytes. There are four payload bytes, but no four-item CPU copy loop on the device-to-computer memory path. This is a schematic example, not an instruction to operate real hardware.The useful separation is that the CPU can perform other work while a larger transfer proceeds. The reasoning is a division of responsibilities: setup specifies the destination and extent once; the transfer engine advances through the payload; completion reports the result. The data still crosses an interconnect such as a computer bus, which must share access among competing initiators. Setup, mapping, synchronization and completion cost work, so DMA does not promise a speedup for every transfer size. [ref]
https://docs.kernel.org/core-api/dma-api.html. James E. J. Bottomley, Linux DMA API, parts Ic–Id: mapping costs, addressing constraints and transfer directions
Correctness also requires keeping the DMA buffer alive and coordinating its ownership until the device is finished. A DMA address need not equal a CPU virtual address or physical address. An IOMMU, when present and configured, translates device addresses and can restrict access to authorized computer memory; it is not the CPU's memory management unit. Operating-system process isolation through virtual memory alone does not establish those device-access restrictions. [ref]
https://docs.kernel.org/core-api/dma-api-howto.html. Linux kernel documentation, Dynamic DMA mapping Guide: CPU and DMA addresses
[ref]https://docs.kernel.org/driver-api/vfio.html. Linux kernel documentation, VFIO: IOMMU protection and device isolation
Past exam of the mathematics course of the University of Cambridge 2006 ia Paper 5 8 a iii Solution Created 2026-09-24 Updated 2026-10-14
With direct memory access, a device can initiate memory transfers, so the processor is no longer the only computer bus master. Requests must be arbitrated to prevent conflicting transfers, and the processor may have to wait while the device owns a shared bus. The operating system must supply valid stable buffers and arrange safe completion before reusing them. On a noncoherent system, cached processor copies must be flushed or invalidated as appropriate so processor and device agree on data. These extra initiators also need suitable address and protection controls.
A hard disk drive pays substantial seek time to position the head and rotational latency to reach the desired sector. After that positioning, neighboring bytes stream past the head quickly. A larger transfer therefore amortizes positioning and command overhead over many bytes.
The physical sector also needs framing, synchronization and error-correcting redundancy. Transferring one byte at a time would spend an excessive fraction of the medium and controller work on that overhead. A controller buffer and a block transfer can efficiently deliver the sector to computer memory, often using direct memory access.
ThusThe choice is a compromise: excessively large blocks waste transfer time for small requests and can increase internal fragmentation in a file system.
