Zou Min wrote: > > Hi, all, > > 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? > Intially, it occured to me that maintaining the information needed to > asscociate disk locations with virtual addresses within the kernel will be > difficult.(possibly requiring the use of has tables, etc.) and I was afraid > to change things in obscure ways. Instead, I was using another approach, namely > to let kernel only output a log of all the swap-ins and address mappings it > performs, and leave it to a user program to complete the missing links. > > However, in this way, logging(using "syslogd" and "klogd") seriously gets > in the way of measuring reads. It would increase disk I/O or disturb the > workload. Especially, when workload is large, log file is also very big. > This needs insance sized kernel log buffer. However when I modified the printk > buffer to 4Mb, system can't even boot up. Also sometimes, I got garbled lines > in log, which may due to differences in processor speed and harddisk speed. > > I was considering to invent a new logging facility, which is more optimized > than "klogd". But it seemed that to reduce interference, I may need to redirect > logs to a harddisk situated on a different harddisk controller, like SCSI. > This requires additional hardware...very troublesome. > > Right now, I am stuck here and deciding whether to improve logging approach, > or try another new way. Much simpler to do the accounting in the kernel and provide a /proc interface to get the data, I think. > 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 small percentage of page faults require disk reads; the majority are serviced from the page cache (under normal conditions). So tracking the number of per-process faults would not tell you much about disk activity. > If so, could you show me some pointers?? > > Thanks in advance! > > -- > Cheers! > > Zou Min Likewise, -- 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/
