At this point, we're handling the majority of file-backed page faults
under the VMA lock, using the ->map_pages entry point. This patch set
attempts to expand that for the following siutations:
- We have to do a read. This could be because we've hit the point in
the readahead window where we need to kick off the next readahead,
or because the page is simply not present in cache.
- We're handling a write fault. Most applications don't do I/O by writes
to shared mmaps for very good reasons, but some do, and it'd be nice
to not make that slow unnecessarily.
- We're doing a COW of a private mapping (both PTE already present
and PTE not-present). These are two different codepaths and I handle
both of them in this patch set.
There is no support in this patch set for drivers to mark themselves
as being VMA lock friendly; they could implement the ->map_pages
vm_operation, but if they do, they would be the first. This is probably
something we want to change at some point in the future, and I've marked
where to make that change in the code.
There is very little performance change in the benchmarks we've run;
mostly because the vast majority of page faults are handled through the
other paths. I still think this patch series is useful for workloads
that may take these paths more often, and just for cleaning up the
fault path in general (it's now clearer why we have to retry in these
cases).
Matthew Wilcox (Oracle) (6):
mm: make lock_folio_maybe_drop_mmap() VMA lock aware
mm: call wp_page_copy() under the VMA lock
mm: handle shared faults under the VMA lock
mm: handle COW faults under the VMA lock
mm: handle read faults under the VMA lock
mm: handle write faults to RO pages under the VMA lock
mm/filemap.c | 13 ++++----
mm/memory.c | 93 ++++++++++++++++++++++++++++++++--------------------
2 files changed, 65 insertions(+), 41 deletions(-)
--
2.25.1