On 2025-02-28 17:32, Peter Xu wrote:
On Fri, Feb 28, 2025 at 12:53:02PM -0500, Mathieu Desnoyers wrote:
On 2025-02-28 11:32, Peter Xu wrote:
On Fri, Feb 28, 2025 at 09:59:00AM -0500, Mathieu Desnoyers wrote:
For the VM use-case, I wonder if we could just add a userfaultfd
"COW" event that would notify userspace when a COW happens ?
I don't know what's the best for KSM and how well this will work, but we
have such event for years.. See UFFDIO_REGISTER_MODE_WP:
https://man7.org/linux/man-pages/man2/userfaultfd.2.html
userfaultfd UFFDIO_REGISTER only seems to work if I pass an address
resulting from a mmap mapping, but returns EINVAL if I pass a
page-aligned address which sits within a private file mapping
(e.g. executable data).
Yes, so far sync traps only supports RAM-based file systems, or anonymous.
Generic private file mappings (that stores executables and libraries) are
not yet supported.
OK, this confirms my observations.
Also, I notice that do_wp_page() only calls handle_userfault
VM_UFFD_WP when vm_fault flags does not have FAULT_FLAG_UNSHARE
set.
AFAICT that's expected, unshare should only be set on reads, never writes.
So uffd-wp shouldn't trap any of those.
I'm confused by your comment. I thought unshare only applies to
*write* faults. What am I missing ?
AFAIU, as it stands now userfaultfd would not help tracking COW faults
caused by stores to private file mappings. Am I missing something ?
I think you're right. So we have UFFD_FEATURE_WP_ASYNC that should work on
most mappings. That one is async, though, so more like soft-dirty. It
might be doable to try making it sync too without a lot of changes based on
how async tracking works.
I'll try this out. It may not matter that it's async given a use-case
use-cases of tracking the age since the WP fault on the COW pages. We
don't need to react to the event in-place to alter its behavior, just
a notification should be fine AFAIU.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
