Tracing Accesses to the Page Cache

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear All,

I have been trying to devise a method to trace *all* accesses to the page cache. This includes reads and writes to pages that are already present in the page cache (which will not be observed if the dirty/referenced bit have not been reset yet by the shrink_list functionality). What I have thought of is implementing a driver similar to the kmmiotrace but for page cache.

What kmmiotrace does is resetting the present bit on PDEs related to a device driver. When the device in question is hit, kmmiotrace has a code path for page fault where is checks if the device being traced is the one we are interested in.
It then records the information of the location addressing the memory, puts the system in single-stepping mode, waits for the next trap and resets the present bit for the remaining accesses. It also terminates the single-stepping mode.

What I am thinking of is implementing a similar, but wholesale scheme for all pages within the page cache. In other words, when a page resides in the page cache, one of the bits (I am thinking of the resetting all access permission bits so a read/write would trigger a GPF), then I would proceed as the kmmiotrace.
I am aware of the massive performance penalty that this methodology probably entails but I am interested in observing each and every access within the page cache.

I wanted to ask the people who obviously know more than me about Linux memory management about how logical such an attempt would be and whether there is a better way that I have missed.

Thanks very much in advance!

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]