In this chapter we describe the Linux 2.4 pagecache. The pagecache is - as the name suggests - a cache of physical pages. In the UNIX world the concept of a pagecache became popular with the introduction of SVR4 UNIX, where it replaced the buffercache for data IO operations.
While the SVR4 pagecache is only used for filesystem data
cache and thus uses the struct vnode and an offset into the file
as hash parameters, the Linux page cache is designed to be more
generic, and therefore uses a struct address_space (explained
below) as first parameter. Because the Linux pagecache is tightly
coupled to the notation of address spaces, you will need at least
a basic understanding of adress_spaces to understand the way the
pagecache works. An address_space is some kind of software MMU
that maps all pages of one object (e.g. inode) to an other
concurrency (typically physical disk blocks). The struct
address_space is defined in include/linux/fs.h
as:
struct address_space { struct list_head clean_pages; struct list_head dirty_pages; struct list_head locked_pages; unsigned long nrpages; struct address_space_operations *a_ops; struct inode *host; struct vm_area_struct *i_mmap; struct vm_area_struct *i_mmap_shared; spinlock_t i_shared_lock; };
To understand the way address_spaces works, we only need to
look at a few of this fields: clean_pages,
dirty_pages and locked_pages are double
linked lists of all clean, dirty and locked pages that belong to
this address_space, nrpages is the total number of
pages in this address_space. a_ops defines the
methods of this object and host is an pointer to the
inode this address_space belongs to - it may also be NULL, e.g.
in the case of the swapper address_space
(mm/swap_state.c,).
The usage of clean_pages,
dirty_pages, locked_pages and
nrpages is obvious, so we will take a tighter look
at the address_space_operations structure, defined
in the same header:
struct address_space_operations { int (*writepage)(struct page *); int (*readpage)(struct file *, struct page *); int (*sync_page)(struct page *); int (*prepare_write)(struct file *, struct page *, unsigned, unsigned); int (*commit_write)(struct file *, struct page *, unsigned, unsigned); int (*bmap)(struct address_space *, long); };
For a basic view at the principle of address_spaces (and the
pagecache) we need to take a look at ->writepage
and ->readpage, but in practice we need to take a
look at ->prepare_write and
->commit_write, too.
You can probably guess what the address_space_operations methods do by virtue of their names alone; nevertheless, they do require some explanation. Their use in the course of filesystem data I/O, by far the most common path through the pagecache, provides a good way of understanding them. Unlike most other UNIX-like operating systems, Linux has generic file operations (a subset of the SYSVish vnode operations) for data IO through the pagecache. This means that the data will not directly interact with the file- system on read/write/mmap, but will be read/written from/to the pagecache whenever possible. The pagecache has to get data from the actual low-level filesystem in case the user wants to read from a page not yet in memory, or write data to disk in case memory gets low.
In the read path the generic methods will first try to find a page that matches the wanted inode/index tuple.
hash = page_hash(inode->i_mapping, index);
Then we test whether the page actually exists.
hash = page_hash(inode->i_mapping, index); page =
__find_page_nolock(inode->i_mapping, index, *hash);
When it does not exist, we allocate a new free page, and add it to the page- cache hash.
page = page_cache_alloc(); __add_to_page_cache(page,
mapping, index, hash);
After the page is hashed we use the ->readpage
address_space operation to actually fill the page with data.
(file is an open instance of inode).
error = mapping->a_ops->readpage(file,
page);
Finally we can copy the data to userspace.
For writing to the filesystem two pathes exist: one for writable mappings (mmap) and one for the write(2) family of syscalls. The mmap case is very simple, so it will be discussed first. When a user modifies mappings, the VM subsystem marks the page dirty.
SetPageDirty(page);
The bdflush kernel thread that is trying to free pages, either
as background activity or because memory gets low will try to
call ->writepage on the pages that are explicitly
marked dirty. The ->writepage method does now
have to write the pages content back to disk and free the
page.
The second write path is _much_ more complicated. For each
page the user writes to, we are basically doing the following:
(for the full code see
mm/filemap.c:generic_file_write()).
page = __grab_cache_page(mapping, index,
&cached_page); mapping->a_ops->prepare_write(file,
page, offset, offset+bytes); copy_from_user(kaddr+offset, buf,
bytes); mapping->a_ops->commit_write(file, page, offset,
offset+bytes);
So first we try to find the hashed page or allocate a new one,
then we call the ->prepare_write address_space
method, copy the user buffer to kernel memory and finally call
the ->commit_write method. As you probably have
seen ->prepare_write and ->commit_write are
fundamentally different from ->readpage and
->writepage, because they are not only called
when physical IO is actually wanted but everytime the user
modifies the file. There are two (or more?) ways to handle this,
the first one uses the Linux buffercache to delay the physical
IO, by filling a page->buffers pointer with
buffer_heads, that will be used in try_to_free_buffers
(fs/buffers.c) to request IO once memory gets low,
and is used very widespread in the current kernel. The other way
just sets the page dirty and relies on
->writepage to do all the work. Due to the lack
of a validitity bitmap in struct page this does not work with
filesystem that have a smaller granuality then
PAGE_SIZE.