How do disk operations affect CPU utilization?

[es619512]

How much is the CPU involved in disk operations. Let's say I have a long disk operation such as copying a large file for several minutes. When I look at the CPU utilization on my computer (Windows XP), it's pretty low; basically zero. So how involved in such an operation is the CPU? Does it just tell the disk to do something and checks back in with the operation every so often to see if it's complete? Should I be able to do CPU intensive tasks like play games while and disk operation is occurring?

What if several disk operations are going on at the same time? Is that more CPU intensive?

Are lots of small CPU operations more intensive than one large one?

What about other types of I/O such as network and memory? How do those affect the CPU?

 

[Bill Simpson]

How much is the CPU involved in disk operations.

It depends. For example with the older IDE (parallel ATE) drives there were PIO (programmed Input Output) modes where the processor was involved in reading each byte from the drive and storing it into memory, but there were also DMA (direct memory access) modes where the processor would send commands to the drive telling it to start the transfer and then dedicated direct memory access hardware that wasn't really part of the CPU would handle the transfer of bytes into memory with no CPU usage. The same is almost certainly true of the newer SATA drives. The PIO modes use far more of the CPU than the DMA and this is reflected in the speed of the transfer.

You should be able to do other things while a file transfer is in process, the few dozen megabytes/second from the drive will use some of the available memory bandwidth, but that probably won't be overwhelming.

The drive may not be able to do more than one transaction at a time.

Currently the CPU is much faster than the time it takes to communicate with external memory, so there is some delay in getting a memory transfer started. The cache is trying to minimize that by providing more rapid access to repeatedly used material.

You might want to try to construct a table showing the relative speeds of a single simple CPU instruction, memory latency to fetch a byte from a new location, latency to fetch a byte from cache, latencies to fetch a page from each of those, transfer speed of a byte from a drive, time for the drive to rotate around to get to a particular sector, time to seek to a particular track on a drive, transfer speed of a byte over a network, etc and see how those compare. Compare all those and try to get a feel for the relative speeds. Remember that drivers and software can add large amounts of delay to all this, but finding information to create that table yourself may give you a better feel for all this.

 

[rcgldr]

Part of the overhead for a file copy is parse the file info to break it up into continuous fragments on a disk, so each fragment is handled via a single large transfer. This will involve some CPU overhead and task switching as the copy goes through each fragment.

Part of the overhead for each transfer is the shared usage of memory bandwidth, and part of the overhead is the setup for each data transfer. For a system with virtual memory, each DMA or bus mastered I/O operation requires all the memory pages containing the I/O buffer be locked and their virtual addresses be translated into physical addresses. The physical addresses and transfer size for each page (to handle partially filled pages), are programmed into "descriptors" in the I/O hardware. If there aren't enough descriptors for the entire transfer, then multiple commands are used or a single comand with partial transfers is done and an interrupt occurs after each partial transfer to reprogram the set of descriptors for the next partial transfer until all of the data is transferred.