DMA 与中断驱动的 I/O [英] dma vs interrupt-driven i/o

问题描述

我有点不清楚 DMA 和中断 I/O 之间的区别.(目前正在阅读操作系统概念，第 7 版).

具体来说，我不确定在这两种情况下中断何时发生，以及在两种情况下 CPU 可以自由做其他工作的时间点.我一直在读的东西，但不一定能调和:

中断驱动

1. 控制器通过驱动程序初始化
2. 控制器检查驱动程序加载的寄存器以决定操作
3. 与外围设备和控制器缓冲区之间的数据传输随之而来.
4. 控制器在以下时间发出中断(读取每个字节时?读取每个字时?缓冲区填满时?传输完成时?
5. 据我所知，CPU 没有做任何事情，同时两者外设 <-> 控制器 I/O 正在发生，并且控制器 <-> MM I/O 正在发生正在发生?
6. 当传输完成或块填满时，CPU 必须初始化从控制器缓冲区到 MM 的传输

DMA

1. 同上，除了控制器能够将数据从其缓冲区直接传输到 MM，无需 CPU 干预.
2. 这是否意味着 CPU 仅在整个传输完成时中断，还是在控制器缓冲区填满时仍中断?
3. 唯一的区别是 CPU 不再需要等待控制器 <-> MM I/O，而是在控制器缓冲区填满时仍然需要中断?或者 DMA 是否也对 CPU 隐藏了这一点?

解决方案

我有点不清楚 DMA 和中断 I/O 之间的区别

DMA 和中断之间的区别是虚假的，因为它们不是对立的概念.
DMA 和中断是正交概念，通常两个概念一起使用.

DMA 的替代方案是编程 I/O，也就是 PIO.
中断的替代方法是轮询.

<块引用>

中断驱动

您需要更具体地了解您所指的内容.
如果系统不使用中断，则必须使用轮询来检测设备状态的变化.

PIO 经常使用中断(来自设备)来启动每个字节/字数据传输.这有助于缓解 PIO 的 CPU 密集型特性.否则，轮询的 PIO 传输将完全消耗 CPU 资源.
但要参考带中断的 PIO"简单地中断"或中断驱动"不准确且具有误导性.

DMA 传输几乎总是使用完成中断(来自 DMA 控制器)来通知 CPU 缓冲区传输已完成.
轮询 DMA 完成(而不是使用完成中断)给 CPU 带来了 DMA 应该减轻的负担.我见过启动 DMA 传输的引导加载程序，然后轮询完成.但这是一个可以承受繁忙等待的单一任务环境，而操作系统需要最大限度地提高 CPU 可用性.这意味着使用具有完成中断的 DMA.

讨论中断"没有提供具体的上下文，例如产生这些中断的来源和原因，可能是造成您困惑的原因.

<块引用>

1. 控制器通过驱动程序初始化
2. 控制器检查驱动程序加载的寄存器以决定操作
3. 与外围设备和控制器缓冲区之间的数据传输随之而来.
4. 控制器在以下时间发出中断(读取每个字节时?读取每个字时?缓冲区填满时?传输完成时?
5. 据我所知，CPU 没有做任何事情，而外围设备 <->控制器 I/O 正在发生，并且控制器 <->MM I/O 正在发生?
6. 当传输完成或块填满时，CPU 必须初始化从控制器缓冲区到 MM 的传输

我在您的问题中看到的一个问题是您提出了一个模棱两可的配置.
您提到了外设"、控制器"、CPU 和MM"(也许是主存?).

从软件的角度来看，外围连接可以是以下拓扑之一:

A.CPU<-->设备

B.CPU<-->控制器 -- [设备或媒体]

C.CPU<-->总线 -- 设备
D.CPU<-->总线 -- 控制器 -- [设备或介质]

Connection A 代表 CPU 可以直接访问的设备，例如用于串行端口的本地 UART.硬件实现中可能会涉及总线，但它们对软件是不可见的.

连接 B 代表通过设备控制器连接到 CPU 的设备，例如MultiMediaCard (MMC) 控制器到 SDcard 和 IDE(集成磁盘控制器)磁盘驱动器.与 A 不同，CPU 必须仅与设备控制器接口，而不是设备本身.控制器与其设备之间的交互通常不受 CPU 控制并且很少受到监控(如果有的话).控制器的存在是为了简化 CPU 与其设备之间的接口.

连接 C 和 D 代表 CPU 可以通过总线(例如 USB、SPI 或 SATA)间接访问的设备或其控制器，例如 USB 到以太网适配器或 SPI NOR 闪存.到设备或其控制器的命令需要通过总线传输.例如，到磁盘控制器的 ATAPI 命令必须通过 SATA 控制器传输.与 A 不同，总线控制器是 CPU 必须直接执行 I/O 的接口.

所以您的 #3 和 #5a 无关紧要.不涉及 CPU.您也不能概括控制器到设备的接口，因为这对于每个外围子系统都是唯一的.一个控制器可能只缓冲一个字节，而另一个控制器将缓冲整个块以验证 ECC.

<块引用>

直接访问

1. 与上面相同，除了控制器能够将数据从其缓冲区直接传输到 MM，而无需 CPU 干预.

2. 这是否意味着 CPU 仅在整个传输完成时中断，还是在控制器缓冲区填满时仍中断?

3. 唯一的区别是CPU不再需要等待控制器<->MM I/O，但是当控制器缓冲区填满时仍然需要中断?或者 DMA 是否也对 CPU 隐藏了这一点?

这些场景和问题几乎没有意义.传输方向未指定，即 CPU 是执行读操作还是写操作).

DMA 传输几乎总是使用完成中断(来自 DMA 控制器)来通知 CPU 缓冲区传输已完成.

您重复使用短语当控制器缓冲区填满时"，而没有指定此数据的来源.如果您问的是设备到控制器 I/O，那么此类 I/O 通常与 CPU 无关，并且状态指示是特定于控制器的.

您似乎在询问块类型的传输.理解块传输并不一定能理解基于字符的 I/O.
有关基于字符 (UART) I/O 的衍生问题，请参阅 基于中断的 UART IO 主控

I'm a little unclear on differences between DMA and interrupt I/O. (Currently reading Operating Systems Concepts, 7th ed).

Specifically, I'm not sure when the interrupts occur in either case, and at what points in both cases is the CPU is free to do other work. Things I've been reading, but can't necessarily reconcile:

Interrupt-driven

1. Controller initialized via driver
2. Controller examines registers loaded by driver in order to decide action
3. Data transfer from/to peripheral and controller's buffer ensues.
4. Controller issues interrupt when (on each byte read? on each word read? when the buffer fills? when the transfer is completed?
5. It is my understanding, that the CPU is not doing anything while both the peripheral <-> controller I/O is taking place, and the controller <-> MM I/O is taking place?
6. When the transfer done, or when block fills up, CPU must initialize transfer from controllers buffer to MM

DMA

1. Same as above, except that the controller is able to transfer data from it's buffer directly to MM without CPU intervention.
2. Does this mean that the CPU is only interrupted when the whole transfer is complete, or is it still interupted when a controller buffer fills up?
3. Is the only difference that the CPU no longer has to wait for the controller <-> MM I/O, but is still has to be interrupted when a controller buffer fills up? Or does DMA hide that from the CPU too?

解决方案

I'm a little unclear on differences between DMA and interrupt I/O

Differences between DMA and interrupts are bogus because they are not opposing concepts.
DMA and interrupts are orthogonal concepts, and both concepts are typically used together.

The alternative to DMA is programmed I/O, aka PIO.
The alternative to interrupts is polling.

Interrupt-driven

You need to be more specific to what you are referring.
If the system is not using interrupts, then it would have to use polling to detect the change in status of a device.

PIO often uses an interrupt (from the device) to initiate each byte/word data transfer. This helps mitigate the CPU-intensive nature of PIO. A polled PIO transfer would otherwise totally consume CPU resources.
But to refer to "PIO with interrupts" as simply "interrupts" or "interrupt-driven" is inaccurate and misleading.

DMA transfers almost alway employ a completion interrupt (from the DMA controller) to notify the CPU that a buffer transfer is complete.
To poll for the DMA completion (instead of using a completion interrupt) bestows a burden on the CPU that DMA is supposed to relieve. I have seen a bootloader that initaited a DMA transfer, and then polled for completion. But that is a single task environment that can afford to busy wait, whereas an operating system needs to maximize CPU availability.. That means using DMA with completion interrupts.

Discussing "interrupts" without providing specific context, e.g. the source and reason why these interrupts being generated, probably is responsible for your confusion.

1. Controller initialized via driver
2. Controller examines registers loaded by driver in order to decide action
3. Data transfer from/to peripheral and controller's buffer ensues.
4. Controller issues interrupt when (on each byte read? on each word read? when the buffer fills? when the transfer is completed?
5. It is my understanding, that the CPU is not doing anything while both the peripheral <-> controller I/O is taking place, and the controller <-> MM I/O is taking place?
6. When the transfer done, or when block fills up, CPU must initialize transfer from controllers buffer to MM

An issue I see with your questions is that you're posing an ambiguous configuration.
You mention a "peripheral", a "controller", the CPU and "MM" (perhaps main memory?).

From a software perspective, the peripheral connection could be one of the following topologies:

A. CPU <--> device

B. CPU <--> controller -- [device or medium]

C. CPU <--> bus -- device
D. CPU <--> bus -- controller -- [device or medium]

Connection A typifies a device that the CPU can access directly, such as a local UART for a serial port. There may be buses involved in the hardware implementation, but they're invisible to software.

Connection B typifies a device that interfaces to the CPU through a device controller, e.g. MultiMediaCard (MMC) controller to SDcard and IDE (integrated disk controller) disk drive. Unlike A, the CPU has to interface only with the device controller, and not the the device itself. The interactions between the controller and its device are typically not controlled by the CPU and minimally monitored (if at all). The controller exists to simplify the interface between CPU and its device.

Connections C and D typifies a device or its controller that the CPU can access indirectly over a bus (e.g. USB, SPI or SATA), such as a USB-to-Ethernet adapter or SPI NOR flash. Command to the device or its controller need to be transmitted over the bus. For example the ATAPI commands to the disk controller have to be transmitted through the SATA controller. Unlike A, the bus controller is the interface that the CPU has to directly perform I/O.

So your #3 and #5a are irrelevant. The CPU is not involved. Also you cannot generalize about the controller-to-device interface, because that can be unique for each peripheral subsystem. One controller may just buffer one byte, whereas another controller will buffer an entire block in order to verify ECC.

DMA

1. Same as above, except that the controller is able to transfer data from it's buffer directly to MM without CPU intervention.

2. Does this mean that the CPU is only interrupted when the whole transfer is complete, or is it still interupted when a controller buffer fills up?

3. Is the only difference that the CPU no longer has to wait for the controller <-> MM I/O, but is still has to be interrupted when a controller buffer fills up? Or does DMA hide that from the CPU too?

These scenarios and questions barely make sense. The direction of the transfer is unspecified, i.e. is the CPU performing a read or write operation).

DMA transfers almost alway employ a completion interrupt (from the DMA controller) to notify the CPU that a buffer transfer is complete.

You repeatedly use the phrase "when a controller buffer fills up" without specifying the source of this data. If you're asking about device-to-controller I/O, then such I/O is typically of minimal concern to the CPU and status indications are controller specific.

You seem to be asking about a block-type of transfer. Understanding block transfers does not necessarily confer understanding of character-based I/O.
For a derivative question on character-based (UART) I/O, see Master for Interrupt based UART IO

这篇关于DMA 与中断驱动的 I/O的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！