My 2 cents on this topic, since I have recently read some litterature about it. On Mon, 14 Feb 2011 16:29:42 +0530 piyush moghe wrote: > While going through Page Cache explanation in "Professional Linux > Kernel" book I came across one term called "address space" ( not > related to virtual or physical address space ) First of all I assume that you are referring to the structure struct addres_space defined in fs.h. See for kernel 2.6.37 the following link http://lxr.linux.no/linux+*/include/linux/fs.h#L632 > > I did not get what is the meaning of this address space, following is > verbatim description: > > "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" > > > Can anyone please explain what is the use of this and what this is all > about? This structure makes up the implementation of the "page cache" mechanism which I see coarsely as a disk cache (of the kind of smartdrv in Windows 3.1 in the conceptual case). The idea is that, in most cases (exceptions are DIRECT_IO disk access) all filesystem reads and writes are performed in memory first. Reads are fetched from disk only the first time and writes are flushed to disk at certain intervals. The most typical use of address_space is with regular files. In these cases the structure is embedded inside the inode (typically in the i_data) and accessed through the i_mapping pointer. It can also be accessed through the f_mapping pointer in the struct file data passed to read() and write() Whenever you want to access a certain offset of a file the procedure goes as follows (skipping access permissions, file locking, reference counting, spin locks, page flags and other issues): 1. Find the address_space of the file through the f_mapping pointer inside struct file. 2. Compute the "page index" of the data to read based on: - the memory page size (e.g. 4 Kb for i386) - the file pointer location (ppos) from previous file operations - the offset specified in the syscall 3. Invoke find_get_page() on the address_space object giving the index. This function is the actual page-cache lookup operation. It goes through the page_tree member of struct adress_space (a radix tree) and if available it returns a pointer of the corresponding struct page. If the page is not yet available or it is not up to date a block I/O operation would be scheduled. Let's assume that the page is available and up to date. So we have a struct page representing the page that holds the cached data. There are still some more tweaks to arrive to the actual data although they fall outside of address_space. 4. From the struct page, the "private" pointer leads to a circular single linked list of struct buffer_head 5. Each buffer head represents an I/O block (as opossed to memory page) chunk of data. The size of the block chunks is stored in b_size. So we need to locate the corresponding i/o block(s) (or buffer_head) inside the linked list that matches the actual data to read. 6. Once the corresponding buffer_head is selected, the ACTUAL DATA is available through the b_data pointer. In all those 6 steps I have given you an overview of the role of - struct address_space - struct page (yes the one of memory pages used everywhere in the kernel) - struct buffer_head in filesystem access. Of course there is much more to tell regarding spin-locks, reference counts, page flags and the like. If you want to get deep in the issue (it took me 3 weeks to understand it) you can read chapters 12, 15 and 16 of Understanding the Linux Kernel book. Hoping it Helps, Miguel PS: Corrections welcome :) -- ----------------------------------------------------------------------- Miguel TELLERIA DE ESTEBAN Grupo de computadores y tiempo real telleriam ENSAIMADA unican.es Dept. ElectrÃnica y Computadores (change "ENSAIMADA" for @) Universidad de Cantabria http://www.ctr.unican.es Tel trabajo: +34 942 201477 -----------------------------------------------------------------------
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
