On Nov 9, 2007 2:46 PM, Wang Yu <wangyuict@xxxxxxxxx> wrote: > Hi, all > First, I want to verify a statement: every opened file has a page cache in Don't mix the userspace stuff with kernelspace. "opened file" is a userspace file descriptor, which may have userspace buffer to store its data, and it is not in terms of pages. This "page cache" are cache memory from the kernel. > memory, there is a struct address_space object associated with it and the address_space concept are per-task basis - and within it is a linked list of VMA. > inode of the opened file has a field i_mapping pointing to the page cache. "inode" found in the mm codes can mean several things - inode of the shared memory (tmpfs, or ramfs, treated as a filesystem object), or inode of the swap file. There is no relationship between those inodes found in the mm codes with the inodes of the filesystem (fs branch of the kernel source). > If processes in system read or write N files concurrently, N files will open up buffer cache (not page cache) in the kernel, which is found in the fs branch, not mm branch. As for how many pages of buffer cache, is not known. there are N page > caches in memory. Is this statement right? > Second, are there some limits about a page cache of a file? for example, the > number of pages in page cache? memory limits are output from /proc/meminfo, which is output from fs/proc/proc_misc.c, and looking at some of the variables used (eg, MemTotal), it is updated in arch/x86/mm/init_32.c: totalram_pages is the global variable. > Thanks! -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
