Tracking Page Faults in Another Process

Tracking Page Faults in Another Process

[Sam Kumar]

Hello, 
I'm writing a performance enhancement tool as a user program for Linux. I wanted to ask about possible ways to achieve this given existing Linux APIs. I also wanted to ask about ideas I have for extending the kernel to implement this---if there's appetite for them, then someone (perhaps myself) may contribute a patch implementing them. 

I am using userfaultfd to track page faults in the target process. I need to "mark" a page in another process, so that any future read or write to that page will result in a page fault captured by userfaultfd. userfaultfd provides a "write-protect" mode, but it only tracks writes to a page; I want to also track reads . So I'm wondering whether userfaultfd could be extended to also support a "read-write-protect" mode that allows for marking pages as both read-protected and write-protected, and detects subsequent page faults on those pages for both reads and writes? If there is any ongoing effort to implement this I would be curious to know; otherwise, if the community thinks it's a good idea, then someone (perhaps myself) may contribute a patch for this. 

An alternative I looked into, to force a future page fault on a page, is process_madvise. Unfortunately, MADV_PAGEOUT doesn't work on pages that are mapped multiple times (see https://elixir.bootlin.com/linux/v6.3.8/source/mm/madvise.c#L479). The MADV_DONTNEED option would work for at least part of my use case, but unfortunately it is not supported with process_madvise (see https://patchwork.kernel.org/project/linux-mm/cover/20210926161259.238054-1-namit@vmware.com/).

If there's appetite for extending the kernel with a read-write-protect mode for userfaultfd, or with support for process_madvise(MADV_DONTNEED), then perhaps I can contribute this. Alternatively, if such extensions are unnecessary because the kernel provides another way of achieving this functionality, then I would love to know! 

(If you reply, please cc me at samkumar@cs.ucla.edu.) 

Thanks, 
Sam Kumar