Page Reclaim and Swapping in the Linux Kernel

This section summarizes the design decisions of the Linux page reclaim subsystem before considering the technical aspects of implementation and examining how requirements are met.

Swapping out pages and all related actions do not appear to be very complicated when the situation is viewed from the high ground without taking development details into consideration. Unfortunately, the very opposite is the case. Hardly any part of the kernel entails as many technical difficulties as the virtual memory subsystem, of which the implementation of swapping is a part. Not only a host of minor hardware details but above all numerous interconnections in the kernel must be taken into account if implementation is to succeed. Speed also plays a crucial role since system performance ultimately depends on memory management performance. Not without reason is memory management one of the hottest kernel development topics, which has given rise to countless discussions, flame wars, and rival implementations.

When discussing the design of the swap subsystem, certain aspects come to mind as characterized by the following questions:

□ How should swap areas on block storage media be organized to ensure not only that pages swapped out can be uniquely identified, but also that memory space is used as effectively as possible to permit read and write operations at maximum speed?

□ Which methods are available to enable the kernel to check when and how many pages need to be swapped out in order to achieve the best possible balance between the provision of free page frames for upcoming needs and minimization of the time needed to perform swap operations?

□ According to which criteria should the pages be selected for swapping? In other words, which page replacement algorithm should be used?

□ How are page faults handled as effectively and quickly as possible, and how are pages returned from a swap area to system RAM?

□ Which data can be removed from the various system caches (from the inode or dentry cache, e.g.) without a backing store because it can be reconstructed indirectly? This question is not, in fact, directly related to the execution of swapping operations but concerns both the cache and swap subsystems. However, as cache shrinking is initiated by the swap subsystem, this question is addressed below in this chapter.

As I have demonstrated, not only are the technical details of paramount importance in achieving an efficient and powerful implementation of the swap system, but the design of the overall system must also support the best possible interaction between the various components to ensure that actions are performed smoothly and harmoniously.

+1 0

Post a comment