Tracking Page Faults in Another Process

From: Sam Kumar
Date: Tue Dec 26 2023 - 20:23:16 EST


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@xxxxxxxxxx/).

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@xxxxxxxxxxx.)

Thanks,
Sam Kumar