Chapter 16: Page and Buffer Cache
only in the situation as seen by the page cache, which is primarily concerned with one specific question:
at which point in timeshould the data be written back? This automatically includes the question as tohow
oftenshould writeback take place.
Understandably, there is no universally valid answer tothis question as different systems with different
load conditions give rise to very different scenarios. For example, a server running overnight receives
very few requests to modify data so that the services of the kernel are seldom required. The same scenario
applies on personal computers when users take a break from work. However, the situation can change
suddenly when the server launches a huge FTP transfer or the PC user starts a lengthy compiler run
to process and produce large volumes of data. In both scenarios, the caches initially have very little to
write back, but then, from one moment to the next, they are required to frequently synchronize with the
underlying storage medium.
For these reasons, the kernel provides several parallel synchronization alternatives:
❑ Several special kernel daemons calledpdflushrun in the background and are activated
periodically — regardless of the current situation in the page cache. They scan the pages in the
cache and write back the data that have not been synchronized with the underlying block device
for a specific period.
Earlier kernel versions employed a userspace daemon namedkudpatedfor this purpose, and
this name is still commonly used to describe this mechanism.
❑ A second operating mode ofpdflushis activated by the kernel if the number of modified data
items in a cache has increased substantially within a short period.
❑ System calls are available to users and applications to instruct the kernel to write back all non-
synchronized data. The best known is thesynccall because there is also a userspace tool of the
same name that builds on it.The various mechanisms used to write back dirty data from the caches are discussed in Chapter 17.
To manage the various target objects that can be processed and cached in whole pages, the kernel uses
an abstraction of the ‘‘address space‘‘that associates the pages in memory with a specific block device (or
any other system unit or part of a system unit).
This type of address space must not be confused with the virtual and physical
address spaces provided by the system or processor. It is a separate abstraction of
the Linux kernel that unfortunately bears the same name.Initially, we are interested in only one aspect. Each address space has a ‘‘host‘‘from which it obtains its
data. In most cases, these are inodes that represent just one file.^2 Because all existing inodes are linked
with their superblock (as discussed in Chapter 8), all the kernel need do is scan a list of all superblocks
and follow their associated inodes to obtain a list of cached pages.
Usually, modifications to files or other objects cached in pages change only part and not the whole of the
page contents. This gives rise to a problem when data are synchronized; it doesn’t make sense to write
(^2) Since the majority of cached pages result from file accesses, most host objects, indeed, represent a regular file. It is, however, also
possible that an inode host object stems from the pseudo-block device filesystem. In this case, the address space is not associated
with a single file, but with a whole block device or a partition thereof.