[0/6] Handle more faults under the VMA lock

Message

Matthew Wilcox Sept. 27, 2023, 5:24 a.m. UTC

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?

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(-)

Comments

Suren Baghdasaryan Sept. 27, 2023, 10:18 p.m. UTC | #1

On Tue, Sep 26, 2023 at 10:25 PM Matthew Wilcox (Oracle)
<[e-mail]> 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
>