more on I/O and DMA

Polling

To make a system work, the OS will need to check regularly if its devices have become ready. This is called polling.

The OS runs at regular intervals (say, once per millisecond) to check each device to see if it is ready. If ready, then the OS further deals with the device.
For a ready keyboard, the character typed is placed into a queue.
For a ready display, the queue is checked. If not empty, then the next character in the queue is sent to the device.

Difficulties with this:

• How often to get the OS to poll? Too little, and input devices may lose data. Too much, and lots of time is wasted checking devices when they are not yet ready.
• How does the OS code get run? The user-level program should not have the responsibility. It has no notion of time. What happens to the user-level program while the OS is polling?

DMA (Direct Memory Access)

The scheme presented so far really only deals with transfers of a single byte or word. There are plenty of devices (networks, disks) that transfer larger blocks of data. These devices also tend to operate much faster than the displays and keyboards and mice.

Having the OS spin wait, or even poll a high speed I/O device (like a disk) would be really inefficent. Spin waiting to transfer a relatively large quantity of data ties up the processor, and polling could not be done often enough to make it efficient (for high-speed devices).

The solution desired will allow block transfers at the speed that the device operates (not the speed at which the processor running the OS code can poll).

So, set up a simple computer (a controller) that can directly access main memory.

    -----------          -----------------           --------------
    |         |          |               |           |            |
    | disk    |<-------->|  controller   |<--------->| memory     |
    |         |          -----------------     / \   |            |
    |         |                                 |    |            |
    -----------                                 |    --------------
						|
					       \ /
                                         ---------------
					 |             |
					 | processor   |
					 |             |
                                         ---------------

• a starting disk address
• a starting memory address
• number of bytes to transfer
• direction of the transfer (disk to memory, or memory to disk)

And, then the processor tells the controller to start the transfer. The controller does the tranfer (at the speed that the disk can handle). The processor checks every once in a while (polls) to see if the transfer is complete.

An issue to ponder: While the disk is reading/writing memory, the processor cannot access memory. How will the processor do anything productive if it cannot access memory?

Possible solutions for this issue:

• Set up a protocol for the access to memory. Give the processor priority.
• Set up a protocol for the access to memory. Give the disk priority.
• Design a memory that can handle 2 requests at the same time. (Note that this is not practical from a design standpoint.)
• Do not worry about it, since the disk does not need every cycle of memory access time. And, if the processor has a cache the processor will not need much access to memory anyway.