On Tue, Sep 26, 2023 at 10:25 PM Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx> wrote: > > 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. > > Suren, would you mind dropping this into your benchmarking setup and > seeing if these relatively minor additions make a difference? Definitely. Thanks for doing this! I'll report once I have some numbers but first I need to review the patches to understand which benchmarks could show the benefit. > > 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.40.1 >
