Zou Min wrote: > > > > I am trying to instrument linux-2.2.19 kernel to measure the number of > > > times each page is read. That is, for each page that is read by each > > > process from disk, there should be a counter. Once the measurement started, > > > the number of times a page is read from disk by a process should be counted; > > > if page is written out to swap space and brought back in, this should be > > > included in the count. > > > > All swap and mmapped pages are already associated with disk > > locations in the kernel, via the address_space structure. > > However, when a page is evicted from RAM, naturally its > > "identity" is destroyed. You would need to keep a list or > > array of mappings between file offsets (or swap id) and > > read count. Attaching such to the address_space struct is > > probably the sensible thing to do. You could then manage > > the read count in the swap.c code when a page is read in > > from disk. Though disk readahead might cause you some > > problems - do you count all reads, or only those initiated > > to service page faults? > > I want to count all reads, such as reading inodes. > In this case, I may have to look into "ll_rw_block()", since this routine > is used for all disk I/O activities, including those not involving swapping. > But, at that level, I only know the block no. How can I still associate > to a block reads to a virtual address? You have the buffer head available, so you can look at buffer_head->b_page->mapping->inode and buffer_head->b_page->index to determine the identity of the page being read in with the buffer. > And, can a block read be interpreated as a page read?(because, as far as > I saw for ext2 fs, one block is usually 4k) In general there could be multiple buffers per page (even for ext2; you can "mke2fs" with 1K blocks if you want); looking at any of them will tell you what you need to know about the page identity. (I think there can also be single buffers of multiple-page size; I'm not quite sure how the page cache copes with that possibility.) > > Much simpler to do the accounting in the kernel and provide a > > /proc interface to get the data, I think. > > Good idea. I may go and try. > > > > That's why I am here to ask you to give me some > > > suggestions. The aim is just to measure the number of each page is read when > > > runing a process. > > > > > > Btw, is it feasible to use or introduce some additional bits in process > > > page-table to accomplish this? > > > > I think that would be enormously more trouble than it's worth, and > > not possible anyway on many platforms. Also, remember that only a > > Why is it so troublesome by modifying page-table? There might not be any (or enough) bits available in a page table entry. This is entirely dependent upon the architecture, and whether the kernel is already using any available "user-defined" PTE bits. Cheers, -- Joe # "You know how many remote castles there are along the # gorges? You can't MOVE for remote castles!" - Lu Tze re. Uberwald # Linux MM docs: http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html - Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ IRC Channel: irc.openprojects.net / #kernelnewbies Web Page: http://www.kernelnewbies.org/
