The addressspace Object

Table 14-1 suggests that the Linux page cache speeds up several different kinds of I/O operations. In fact, the page cache may include the following types of pages:

• Pages containing data of regular files and directories of disk-based filesystems; in Chapter 15, we describe how the kernel handles read and write operations on them.

• Pages containing data of a memory-mapped file; see Chapter 15 for details.

• Pages containing data directly read from block device files (skipping the filesystem layer); as discussed in Chapter 15, the kernel handles them using the same set of functions as for pages containing data of regular files.

• Pages containing data of User Mode processes that have been swapped out on disk. As we shall see in Chapter 16, the kernel could be forced to keep in the page cache some pages whose contents have been already written on a swap area.

• Pages belonging to an Interprocess Communication (IPC) shared memory region; we describe IPC resources in Chapter 19.

So far, so good, but how is the kernel supposed to keep track of how every page in the page cache should be handled? For instance, suppose the kernel wishes to update the content of a page included in the page cache — reading the page contents from a regular file, from a directory, from a block device file, or from a swap area are quite different operations, and the kernel must execute the proper operation according to the type of page.

The key data structure that establishes the relationship between pages and methods that operate on the pages is the address_space object. Formally, each address_space object establishes a link between a generic kernel object (the so-called owner) and a set of methods that operate on the pages belonging to the owner.

As stated before, the page cache includes five kinds of pages, so a page may belong to five possible kinds of owners.

For instance, if a page belongs to a regular file that is stored in an Ext2 filesystem, the owner of the page is an inode object. The i_mapping field of this object points to an address_space object. In turn, the address_space object defines a set of methods that allow the kernel to act on the pages containing the data of our regular file.

Specifically, the address_space object includes the fields shown in Table 14-2.

Table 14-2. The fields of the address_space object




struct list head

clean pages

List of owner's clean pages

struct list head

dirty pages

List of owner's nonlocked dirty pages

struct list head

locked pages

List of owner's locked dirty pages

unsigned long


Total number of owner's pages

struct address space operations *

a ops

Methods that operate on the owner's pages

struct inode *


Pointer to the owning inode

struct vm area struct *

i mmap

List of memory regions for private memory mapping

struct vm area struct *

i mmap shared

List of memory regions for shared memory mapping

spinlock t

i shared lock

Spin lock for the lists of memory regions


gfp mask

Memory allocator flags for the owner's pages

The clean_pages, dirty_pages, and locked_pages fields represent the heads of three lists of page descriptors. Together, these lists include all pages that belong to the owner of the address_space object. We discuss the role of each list in the next section. The nrpages field stores the total number of pages inserted in the three lists.

Although the owner of the address_space object could be any generic kernel object, usually it is a VFS inode object. (After all, the page cache was introduced to speed up disk accesses!) In this case, the host field points to the inode that owns the address_space object.

The i mmap, i mmap shared, i shared lock, and gfp mask fields are used whenever the owner of the address_space object is an inode of a memory-mapped file. We discuss

The most important field of the address_space object is a_ops, which points to a table of type address_space_operations containing the methods that define how the owner's pages are handled. These methods are shown in Table 14-3.

Table 14-3. The methods of the address_space object




Write operation (from the page to the owner's disk image)


Read operation (from the owner's disk image to the page)

sync page

Start the I/O data transfer of already scheduled operations on the page

prepare write

Prepare the write operation (used by disk-based filesystems)

commit write

Complete the write operation (used by disk-based filesystems)


Get a logical block number from a file block index


Prepare to delete the page from the owner's disk image


Used by journaling filesystems to prepare the release of a page

direct IO

Direct I/O transfer of the data of the page

The most important methods are readpage, writepage, prepare write, and commit_write. We discuss them in Chapter 15. In most cases, the methods link the owner inode objects with the low-level drivers that access the physical devices. For instance, the function that implements the readpage method for an inode of a regular file "knows" how to locate the positions on the physical disk device of the blocks corresponding to any page of the file. In this chapter, however, we don't have to discuss the address_space methods further.

Continue reading here: The page hash table

Was this article helpful?

+1 0