15
votes

Can dirtiness of pages of a (non-shared) mmap be accessed from userspace under linux 2.6.30+? Platform-specific hacks and kludges welcome.

Ideally, I'm looking for an array of bits, one per page (4kB?) of the mmap'ed region, which are set if that page has been written to since the region was mmap'ed.

(I am aware, that the process doing the writing could keep track of this information - but it seems silly to do so if the kernel is doing it anyway.)

Thanks,

Chris.

5

5 Answers

12
votes

See /proc/*/pagemap and /proc/kpageflags interfaces. First tells you PFN for an address, second tells you dirty bit given PFN.

See fs/proc/task_mmu.c , Documentation/vm/pagemap.txt, Documentation/vm/page-types.c .

5
votes

The traditional solution is to mprotect to read only, and then handle the sigsegv and mark dirty before reprotecting to allow writes. We did this at ObjectStore a long time ago for this very purpose.

2
votes

generic_writepages and balance_dirty_pages_ratelimited_nr appear to be the entry points into the kernel (2.6.20) that are related to dirty pages. I hope they work in 2.6.30+ as well. Interesting question, can I ask what you are writing that requires such control over the pages?

1
votes

This data would be continually out of date - it's possible the page may be written back after your process sees the page is dirty.

That said, tone way is to map it in one-page chunks, then look at /proc/pid/smaps to see if the chunks are dirty - that said, this may fail if the kernel merges the pages.

Unfortunately, since the page tables aren't visible to the user space process, that's about the best you can do without a kernel patch of some sort.

0
votes

If your array of bits is small enough, perhaps you can use the debug registers on Intel (though I am not sure on how it is done on linux).