Mmswapstatec

struct address_space swapper_space = {

•page_tree = RADIX_TREE_INIT(GFP_ATOMIC|_GFP_NOWARN),

.tree_lock = RW_LOCK_UNLOCKED(swapper_space.tree_lock),

.i_mmap_nonlinear = LIST_HEAD_INIT(swapper_space.i_mmap_nonlinear), .backing_dev_info = &swap_backing_dev_info,

Although each system may have several swap areas, there is just one variable via which the remaining kernel code accesses the swap cache. The pages are not organized into different areas until the data are actually written back. In the view of that part of the kernel that determines which pages are to be swapped out, there is only one swap cache to which the appropriate instructions must be forwarded, and this cache is represented by the swapper_space object mentioned above.

Since most of the fields are lists, they are initialized to their (empty) basic settings using suitable macros. The meaning of the entries is discussed in Chapter 4.

The kernel provides a set of swap cache access functions that can be used by any kernel code involved with memory management. They allow, for example, pages to be added to the swap cache or a search to be made for pages in the cache. They constitute the interface between the swap cache and the page replacement logic and are therefore used to issue commands to swap pages in or out without having to worry about the technical details of how the data are subsequently transferred.

A set of functions is also provided to handle with the address space made available by the swap cache. As is common with address spaces and therefore with page caches, these functions are grouped into an address_space_operations instance that is associated with swapper_space by means of the aops element. The functions constitute the ''downward'' interface of the swap cache; in other words, to the data transfer implementation between the system's swap areas and RAM memory. In contrast to the function set mentioned earlier, these routines are not concerned with which pages are swapped out or in or when this is done, but are responsible for the technical aspects of data transfer for the selected pages.

swap_aops is defined as follows: mm/page_io.c static struct address_space_operations swap_aops = { .writepage = swap_writepage, .sync_page = block_sync_page, .set_page_dirty = _set_page_dirty_nobuffers,

We will look at the significance and implementation of these functions more closely later on. Initially, it is sufficient to outline what they do:

1. swap_writepage synchronizes dirty pages with the underlying block device. This is not done to maintain consistency between RAM memory and the block device, as is the case for all other page caches. Its purpose is to remove pages from the swap cache and to transfer their data to a swap area. The function is therefore responsible for implementing data transfer between RAM memory and the swap area on the disk.

2. Pages must be marked as ''dirty'' in the swap cache without having to allocate new memory — a resource that is scarce enough anyway when swap-out mechanisms are used. As discussed in Chapter 16, one possible procedure to mark pages as dirty is to create buffers that enable the data to be written back chunk-by-chunk. However, additional memory is needed to hold the buffer_head instances that store the required management data. This is pointless as only complete pages in the swap cache are written back anyway.

The_set_page_dirty_nobuffers function is therefore used to mark pages as dirty; it sets the PG_dirty flag but does not create buffers.

3. As with most other page caches, the standard implementation of the kernel (block_sync_page) is used to synchronize pages in the swap area. This function does nothing more than unplug to corresponding block queues. As far as the swap cache is concerned, this means that all data transfer requests forwarded to the block layer are then executed.

All ''static'' elements of the swap cache have been introduced, and the fundamentals upon which the swapping implementation rests are in place. Before discussing how they are brought to use in live action, let us briefly survey the functions that we will encounter in due course — there is a considerable number of them. Figure 18-7 shows the most important ones and how they are connected.

The figure resembles the rough overview from Figure 18-4, but provides many more details. The general structure introduced there can be immediately recognized. The individual functions that realize this structure are discussed in the remainder of this chapter.

Continue reading here: Adding New Pages

Was this article helpful?

0 0