Swapping Process in Operating System | OS Tutorials

In an operating system, a process should be resident in memory to be executed. A process can be swapped temporarily out of memory to a backing store and then brought back into memory for continued execution. Memory management can be effective by having many processes in memory at once. In a batch system, if the OS cannot allocate memory to start a new job, it can “recover” by simply delaying starting the job.

Swapping in OS

If there is a queue of jobs waiting to be created, the OS might want to go down the list, looking for a smaller job that can be created right away. This approach maximizes utilization of memory, but can starve large jobs. The situation is analogous to short-term CPU scheduling, in which SJF gives optimal CPU utilization but can starve long bursts.

• The same trick works here: aging. As a job waits longer and longer, increase its priority until its priority is so high that the OS refuses to skip over it looking for a more recently arrived but smaller job.
• An alternative way of avoiding starvation is to use a memory-allocation scheme with fixed partitions (holes are not split or combined).
• Assuming no job is bigger than the biggest partition, there will be no starvation, provided that each time a partition is freed, we start the first job in line that is smaller than that partition.
• However, we have another choice analogous to the difference between first-fit and best-fit. Of course, we want to use the “best” hole for each job (the smallest free partition that is at least as big as the job), but suppose the next job in line is small and all the small partitions are currently in use
• We might want to delay starting that job and look through the arrival queue for a job that better uses the partitions currently available. This policy re-introduces the possibility of starvation.
• If a disk is available, we can also swap blocked jobs out to disk. When a job finishes, we first swap back jobs from disk before allowing new jobs to start.
• When a job is blocked (either because it wants to do I/O or because our short-term scheduling algorithm says to switch to another job), we have a choice of leaving it in memory or swapping it out.
• One way of looking at this scheme is that it increases the multiprogramming level (the number of jobs “in memory”) at the cost of making it (much) more expensive to switch jobs.
• A variant of the MLFQ (multi-level feedback queues) CPU scheduling algorithm is particularly attractive for this situation.
• The queues are numbered from 0 up to some maximum. When a job becomes ready, it enters queue zero. The CPU scheduler always runs a job from the lowest-numbered non-empty queue (i.e., the priority is the negative of the queue number). It runs a job from queue i for a maximum of iquantam.
• If the job does not block or complete within that time limit, it is added to the next higher queue. This algorithm behaves like RR with a short quantum in that short bursts get high priority, but does not incur the overhead of frequent swaps between jobs with long bursts.
• The number of swaps is limited to the logarithm of the burst size.
• Figure 1 shows the concept of swapping with swap-in and swap-out of two processes.

• This scheme is applicable in several ways; consider an example of a multiprogramming environment with a round-robin CPU scheduling algorithm.
• When a quantum expires, the memory manager will start to swap out the process that just finished, and to swap in another process to the memory space that has been freed.
• In the meantime, the CPU scheduler will allocate a time slice to some other process in memory. When each process finishes its time quantum, it will be swapped with another process.
• Hence, the memory manager can swap processes fast enough so that there are always processes in memory, ready to execute.
• We can also implement this scheme in priority-based scheduling algorithms. Since in priorty based approach, priority is associated with each process.
• If a higher-priority process arrives and wants the service, the memory manager can swap out the lower-priority process so that higher priorty process can execute.
• When the higher-priority process finishes, the lower-priority process can be swapped back in and continued.
• Hence, this swapping is also sometimes called roll out and Roll-in. Normally, a process that is swapped out will be swapped back into the same memory space that is occupied previously. This is done by address binding.
• If execution time binding is being used, then it is possible to swap a process into a different memory space.
• Swapping process requires a backing store. It is commonly a fast disk which contains memory images for users.
• Swapping is well suited to a time-sharing system. The context switch time in such a swapping system is fairly high. The major part of the swap time is transfer time. The total transfer time is directly proportional to the amount of memory swapped.
• The system maintains a ready queue consisting of all processes whose memory images are on the backing store or in memory and are ready to run.
• Whenever the CPU scheduler wants to execute a process, it calls the dispatcher.

Working of Dispatcher in Swapping

• The dispatcher checks in memory whether the next process in the queue exists in it or not.
• If the process is not in memory and there is no free memory space, then the dispatcher swaps out a process currently in memory and swaps in the desired process.
• It then reloads registers as normal and transfers control to the selected process.

Constraints on Swapping

• If we want to swap a process, we must be sure that it is completely idle.
• If a process is waiting for an I/O operation and we want to swap that process to free up its memory, and if the I/O is asynchronously accessing the user memory for an I/O buffer, then the process cannot be swapped.

Solution for These Constraints

• The two main solutions to this problem are –
  1. Never to swap a process with pending I/O.
  2. To execute I/O operations only into operating system buffers.