BBS水木清华站∶精华区

发信人: flamingo (火烈鸟), 信区: Linux        
标  题: 第四章(Linux Kernel Internals)! 
发信站: BBS 水木清华站 (Wed Dec 20 19:35:10 2000) 
 
4. Linux Page Cache 
In this chapter we describe the Linux 2.4 pagecache. The pagecache is - as t 
he 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 r 
eplaced the buffercache for data IO operations. 
While the SVR4 pagecache is only used for filesystem data cache and thus use 
s 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 addr 
ess_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 blo 
cks). The struct address_space is defined in include/linux/fs.h as: 
---------------------------------------------------------------------------- 
---- 
        struct address_space { 
                struct list_head                        pages; 
                unsigned long                           nrpages; 
                struct address_space_operations *       a_ops; 
                void *                                  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 
 these fields: pages is a double linked list of all pages that belong to thi 
s address_space, nrpages is the number of pages in pages, a_ops defines the  
methods of this address_space and host is a opaque pointer to the object thi 
s address_space belongs to. The usage of 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 n 
eed 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 virtu 
e of their names alone; nevertheless, they do require some explanation. Thei 
r use in the course of filesystem data I/O, by far the most common path thro 
ugh the pagecache, provides a good way of understanding them. Unlike most ot 
her UNIX-like operating systems, Linux has generic file operations (a subset 
 of the SYSVish vnode operations) for data IO through the pagecache. This me 
ans that the data will not directly interact with the file- system on read/w 
rite/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 matc 
hes 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 ac 
tually 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 (m 
map) and one for the write(2) family of syscalls. The mmap case is very simp 
le, so it will be discussed first. When a user modifies mappings, the VM sub 
system 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 pag 
es 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 wri 
tes to, we are basically doing the following: (for the full code see mm/file 
map.c:generic_file_write()). 
page = __grab_cache_page(mapping, index, &cached_page); mapping->a_ops->prep 
are_write(file, page, offset, offset+bytes); copy_from_user(kaddr+offset, bu 
f, 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 mem 
ory 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 actua 
lly 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 wil 
l be used in try_to_free_buffers (fs/buffers.c) to request IO once memory ge 
ts low, and is used very widespread in the current kernel. The other way jus 
t sets the page dirty and relies on ->writepage to do all the work. Due to t 
he lack of a validitity bitmap in struct page this does not work with filesy 
stem that have a smaller granuality then PAGE_SIZE. 
 
-- 
WORLD IS NOT YOURS 
 
 
※ 来源:·BBS 水木清华站 smth.org·[FROM: 162.105.53.152] 

BBS水木清华站∶精华区