mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Barry Song <21cnbao@gmail.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org, chrisl@kernel.org,
	surenb@google.com, kasong@tencent.com, minchan@kernel.org,
	willy@infradead.org, ryan.roberts@arm.com,
	linux-kernel@vger.kernel.org, Barry Song <v-songbaohua@oppo.com>
Subject: Re: [RFC PATCH] mm: swap: reuse exclusive folio directly instead of wp page faults
Date: Fri, 31 May 2024 14:34:54 +0200	[thread overview]
Message-ID: <821d29b9-cb06-49db-9fe8-6c054c8787fb@redhat.com> (raw)
In-Reply-To: <CAGsJ_4yX52k=Wx2x3jwXzNBG=rDGJrzGNwGCAh0puUP7zby=QA@mail.gmail.com>

On 31.05.24 14:30, Barry Song wrote:
> On Sat, Jun 1, 2024 at 12:20 AM Barry Song <21cnbao@gmail.com> wrote:
>>
>> On Sat, Jun 1, 2024 at 12:10 AM David Hildenbrand <david@redhat.com> wrote:
>>>
>>> On 31.05.24 13:55, Barry Song wrote:
>>>> On Fri, May 31, 2024 at 11:08 PM David Hildenbrand <david@redhat.com> wrote:
>>>>>
>>>>> On 31.05.24 12:48, Barry Song wrote:
>>>>>> From: Barry Song <v-songbaohua@oppo.com>
>>>>>>
>>>>>> After swapping out, we perform a swap-in operation. If we first read
>>>>>> and then write, we encounter a major fault in do_swap_page for reading,
>>>>>> along with additional minor faults in do_wp_page for writing. However,
>>>>>> the latter appears to be unnecessary and inefficient. Instead, we can
>>>>>> directly reuse in do_swap_page and completely eliminate the need for
>>>>>> do_wp_page.
>>>>>>
>>>>>> This patch achieves that optimization specifically for exclusive folios.
>>>>>> The following microbenchmark demonstrates the significant reduction in
>>>>>> minor faults.
>>>>>>
>>>>>>     #define DATA_SIZE (2UL * 1024 * 1024)
>>>>>>     #define PAGE_SIZE (4UL * 1024)
>>>>>>
>>>>>>     static void *read_write_data(char *addr)
>>>>>>     {
>>>>>>             char tmp;
>>>>>>
>>>>>>             for (int i = 0; i < DATA_SIZE; i += PAGE_SIZE) {
>>>>>>                     tmp = *(volatile char *)(addr + i);
>>>>>>                     *(volatile char *)(addr + i) = tmp;
>>>>>>             }
>>>>>>     }
>>>>>>
>>>>>>     int main(int argc, char **argv)
>>>>>>     {
>>>>>>             struct rusage ru;
>>>>>>
>>>>>>             char *addr = mmap(NULL, DATA_SIZE, PROT_READ | PROT_WRITE,
>>>>>>                             MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
>>>>>>             memset(addr, 0x11, DATA_SIZE);
>>>>>>
>>>>>>             do {
>>>>>>                     long old_ru_minflt, old_ru_majflt;
>>>>>>                     long new_ru_minflt, new_ru_majflt;
>>>>>>
>>>>>>                     madvise(addr, DATA_SIZE, MADV_PAGEOUT);
>>>>>>
>>>>>>                     getrusage(RUSAGE_SELF, &ru);
>>>>>>                     old_ru_minflt = ru.ru_minflt;
>>>>>>                     old_ru_majflt = ru.ru_majflt;
>>>>>>
>>>>>>                     read_write_data(addr);
>>>>>>                     getrusage(RUSAGE_SELF, &ru);
>>>>>>                     new_ru_minflt = ru.ru_minflt;
>>>>>>                     new_ru_majflt = ru.ru_majflt;
>>>>>>
>>>>>>                     printf("minor faults:%ld major faults:%ld\n",
>>>>>>                             new_ru_minflt - old_ru_minflt,
>>>>>>                             new_ru_majflt - old_ru_majflt);
>>>>>>             } while(0);
>>>>>>
>>>>>>             return 0;
>>>>>>     }
>>>>>>
>>>>>> w/o patch,
>>>>>> / # ~/a.out
>>>>>> minor faults:512 major faults:512
>>>>>>
>>>>>> w/ patch,
>>>>>> / # ~/a.out
>>>>>> minor faults:0 major faults:512
>>>>>>
>>>>>> Minor faults decrease to 0!
>>>>>>
>>>>>> Signed-off-by: Barry Song <v-songbaohua@oppo.com>
>>>>>> ---
>>>>>>     mm/memory.c | 7 ++++---
>>>>>>     1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/mm/memory.c b/mm/memory.c
>>>>>> index eef4e482c0c2..e1d2e339958e 100644
>>>>>> --- a/mm/memory.c
>>>>>> +++ b/mm/memory.c
>>>>>> @@ -4325,9 +4325,10 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>>>>>          */
>>>>>>         if (!folio_test_ksm(folio) &&
>>>>>>             (exclusive || folio_ref_count(folio) == 1)) {
>>>>>> -             if (vmf->flags & FAULT_FLAG_WRITE) {
>>>>>> -                     pte = maybe_mkwrite(pte_mkdirty(pte), vma);
>>>>>> -                     vmf->flags &= ~FAULT_FLAG_WRITE;
>>>>>> +             if (vma->vm_flags & VM_WRITE) {
>>>>>> +                     pte = pte_mkwrite(pte_mkdirty(pte), vma);
>>>>>> +                     if (vmf->flags & FAULT_FLAG_WRITE)
>>>>>> +                             vmf->flags &= ~FAULT_FLAG_WRITE;
>>>>>
>>>>> This implies, that even on a read fault, you would mark the pte dirty
>>>>> and it would have to be written back to swap if still in the swap cache
>>>>> and only read.
>>>>>
>>>>> That is controversial.
>>>>>
>>>>> What is less controversial is doing what mprotect() via
>>>>> change_pte_range()/can_change_pte_writable() would do: mark the PTE
>>>>> writable but not dirty.
>>>>>
>>>>> I suggest setting the pte only dirty if FAULT_FLAG_WRITE is set.
>>>>
>>>> Thanks!
>>>>
>>>> I assume you mean something as below?
>>>
>>> It raises an important point: uffd-wp must be handled accordingly.
>>>
>>>>
>>>> diff --git a/mm/memory.c b/mm/memory.c
>>>> index eef4e482c0c2..dbf1ba8ccfd6 100644
>>>> --- a/mm/memory.c
>>>> +++ b/mm/memory.c
>>>> @@ -4317,6 +4317,10 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>>>           add_mm_counter(vma->vm_mm, MM_SWAPENTS, -nr_pages);
>>>>           pte = mk_pte(page, vma->vm_page_prot);
>>>>
>>>> +       if (pte_swp_soft_dirty(vmf->orig_pte))
>>>> +               pte = pte_mksoft_dirty(pte);
>>>> +       if (pte_swp_uffd_wp(vmf->orig_pte))
>>>> +               pte = pte_mkuffd_wp(pte);
>>>>           /*
>>>>            * Same logic as in do_wp_page(); however, optimize for pages that are
>>>>            * certainly not shared either because we just allocated them without
>>>> @@ -4325,18 +4329,19 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>>>>            */
>>>>           if (!folio_test_ksm(folio) &&
>>>>               (exclusive || folio_ref_count(folio) == 1)) {
>>>> -               if (vmf->flags & FAULT_FLAG_WRITE) {
>>>> -                       pte = maybe_mkwrite(pte_mkdirty(pte), vma);
>>>> -                       vmf->flags &= ~FAULT_FLAG_WRITE;
>>>> +               if (vma->vm_flags & VM_WRITE) {
>>>> +                       if (vmf->flags & FAULT_FLAG_WRITE) {
>>>> +                               pte = pte_mkwrite(pte_mkdirty(pte), vma);
>>>> +                               vmf->flags &= ~FAULT_FLAG_WRITE;
>>>> +                       } else if ((!vma_soft_dirty_enabled(vma) ||
>>>> pte_soft_dirty(pte))
>>>> +                                   && !userfaultfd_pte_wp(vma, pte)) {
>>>> +                                       pte = pte_mkwrite(pte, vma);
>>>
>>> Even with FAULT_FLAG_WRITE we must respect uffd-wp and *not* do a
>>> pte_mkwrite(pte). So we have to catch and handle that earlier (I could
>>> have sworn we handle that somehow).
>>>
>>> Note that the existing
>>>          pte = pte_mkuffd_wp(pte);
>>>
>>> Will fix that up because it does an implicit pte_wrprotect().
>>
>> This is exactly what I have missed as I am struggling with why WRITE_FAULT
>> blindly does mkwrite without checking userfaultfd_pte_wp().
>>
>>>
>>>
>>> So maybe what would work is
>>>
>>>
>>> if ((vma->vm_flags & VM_WRITE) && !userfaultfd_pte_wp(vma, pte) &&
>>>       !vma_soft_dirty_enabled(vma)) {
>>>          pte = pte_mkwrite(pte);
>>>
>>>          /* Only set the PTE dirty on write fault. */
>>>          if (vmf->flags & FAULT_FLAG_WRITE) {
>>>                  pte = pte_mkdirty(pte);
>>>                  vmf->flags &= ~FAULT_FLAG_WRITE;
>>>          }
> 
> WRITE_FAULT has a pte_mkdirty, so it doesn't need to check
> "!vma_soft_dirty_enabled(vma)"?
> Maybe I thought too much, just the simple code below should work?

That would likely not handle softdirty correctly in case we end up in 
pte_mkwrite(pte, vma); note that pte_mksoft_dirty() will not wrprotect ...

(note that we shouldn't optimize for softdirty handling)

> 
>          if (!folio_test_ksm(folio) &&
>              (exclusive || folio_ref_count(folio) == 1)) {
>                  if (vma->vm_flags & VM_WRITE) {
>                          if (vmf->flags & FAULT_FLAG_WRITE) {
>                                  pte = pte_mkwrite(pte_mkdirty(pte), vma);
>                                  vmf->flags &= ~FAULT_FLAG_WRITE;
>                          } else {
>                                  pte = pte_mkwrite(pte, vma);
>                          }
>                  }
>                  rmap_flags |= RMAP_EXCLUSIVE;
>          }
> 
>          if (pte_swp_soft_dirty(vmf->orig_pte))
>                  pte = pte_mksoft_dirty(pte);
>          if (pte_swp_uffd_wp(vmf->orig_pte))
>                  pte = pte_mkuffd_wp(pte);
> 
> This still uses the implicit wrprotect of pte_mkuffd_wp.

But the wrprotected->writable->wrprotected path really is confusing. I'd 
prefer to set these bits ahead of time instead, so we can properly rely 
on them -- like we do in other code.

-- 
Cheers,

David / dhildenb


  reply	other threads:[~2024-05-31 12:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-31 10:48 Barry Song
2024-05-31 11:08 ` David Hildenbrand
2024-05-31 11:55   ` Barry Song
2024-05-31 12:10     ` David Hildenbrand
2024-05-31 12:20       ` Barry Song
2024-05-31 12:30         ` Barry Song
2024-05-31 12:34           ` David Hildenbrand [this message]
2024-06-01  0:48             ` Barry Song
2024-06-01  6:44               ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=821d29b9-cb06-49db-9fe8-6c054c8787fb@redhat.com \
    --to=david@redhat.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chrisl@kernel.org \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=surenb@google.com \
    --cc=v-songbaohua@oppo.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®