Why can't OSes swap out processes that are waiting for I/O?

Question

In the book, Operating System Concepts, 9th Edition, there is this paragraph that I don't quite wrap my head around.

Swapping is constrained by other factors as well. If we want to swap a process, we must be sure that it is completely idle. Of particular concern is any pending I/O. A process may be waiting for an I/O operation when we want to swap that process to free up memory. However, if the I/O is asynchronously accessing the user memory for I/O buffers, then the process cannot be swapped. Assume that the I/O operation is queued because the device is busy. If we were to swap out process P1 and swap in process P2, the I/O operation might then attempt to use memory that now belongs to process P2. There are two main solutions to this problem: never swap a process with pending I/O, or execute I/O operations only into operating-system buffers. Transfers between operating-system buffers and process memory then occur only when the process is swapped in. Note that this double buffering itself adds overhead. We now need to copy the data again, from kernel memory to user memory, before the user process can access it.

This is quite a handful for me to swallow for now. I have a lot of questions.

• What are I/O buffers? Are they located in the I/O device?
• How and why does the I/O asynchronously access user memory?
• Why would an I/O operation attempt to use P2 memory when P1 gets swapped with P2?

To probably generalize my questions, why shouldn't we swap processes with pending I/O? If we do so, would there be memory corruption or segmentation faults?

Answer 1

One scenario that can explain this more obviously is as follow: Suppose that a process wanted to read a disk block to a buffer in its address space (An I/O buffer is just a portion of the processe's memory. eg. char[1024]). The process will make a system call to ask the OS to issue an I/O to read the corresponding disk block into that buffer in the memory of the process and then the process sleeps waiting for this I/O operation to complete (Because it may take some time before the operation is completed by the device and at that time we can schedule another process for execution instead of letting the CPU idle). Now, to execute that I/O, the OS will probably program some kind of DMA (Direct Memory Access) device to automatically copy the data from the disk controller to the the buffer in the memory of the process without having to interrupt the CPU (Hence, the name direct access to memory). Now, if it happens that the process is swapped out, its physical memory will be freed (the memory where the buffer that receives the disk block content from the DMA is situated) and it will probably be allocated for another process. Which means that, when the DMA starts to copy the disk block content to the initially provided memory buffer (Initial buffer that was later freed and given to another process while the disk block was being read), that content is not actually being copied to the sleeping process's memory but some other process memory. And that's why the OS should not swap a process waiting for I/O. Otherwise, don't program the DMA to copy the disk content directly to the process's memory buffer but instead copy everything into some kernel buffer (Kernel memory) and then copy that content into the process memory again once it's ready (Swapped in) but this is a double duty and may incur some overhead.

Hence:- So we can say that resources generated after the i/o processing for the original requesting process might be swapped with some other process, due to swapping of memory spaces between the processes.

Answer 2

Your OS book seems to be a bit of an antique.

Here’s where you need to be careful: You can’t remove the _ address space_ for an application. But with a 64 bit OS, you have tons of address space at practically no cost. And you need active I/O buffers to stay in memory where you are, which is also no problem whatsoever.