From: Yu Zhao <yuzhao@google.com>
To: Yin Fengwei <fengwei.yin@intel.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, willy@infradead.org,
david@redhat.com, ryan.roberts@arm.com, shy828301@gmail.com
Subject: Re: [RFC PATCH v2 2/3] mm: handle large folio when large folio in VM_LOCKED VMA range
Date: Wed, 12 Jul 2023 00:23:23 -0600 [thread overview]
Message-ID: <CAOUHufZQ0EpyRZ_jAMxs8uNSQOz6uAkzVjvvgD+4wBvmgHJoCA@mail.gmail.com> (raw)
In-Reply-To: <20230712060144.3006358-3-fengwei.yin@intel.com>
On Wed, Jul 12, 2023 at 12:02 AM Yin Fengwei <fengwei.yin@intel.com> wrote:
>
> If large folio is in the range of VM_LOCKED VMA, it should be
> mlocked to avoid being picked by page reclaim. Which may split
> the large folio and then mlock each pages again.
>
> Mlock this kind of large folio to prevent them being picked by
> page reclaim.
>
> For the large folio which cross the boundary of VM_LOCKED VMA,
> we'd better not to mlock it. So if the system is under memory
> pressure, this kind of large folio will be split and the pages
> ouf of VM_LOCKED VMA can be reclaimed.
>
> Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
> ---
> mm/internal.h | 11 ++++++++---
> mm/rmap.c | 34 +++++++++++++++++++++++++++-------
> 2 files changed, 35 insertions(+), 10 deletions(-)
>
> diff --git a/mm/internal.h b/mm/internal.h
> index c7dd15d8de3ef..776141de2797a 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -643,7 +643,8 @@ static inline void mlock_vma_folio(struct folio *folio,
> * still be set while VM_SPECIAL bits are added: so ignore it then.
> */
> if (unlikely((vma->vm_flags & (VM_LOCKED|VM_SPECIAL)) == VM_LOCKED) &&
> - (compound || !folio_test_large(folio)))
> + (compound || !folio_test_large(folio) ||
> + folio_in_range(folio, vma, vma->vm_start, vma->vm_end)))
> mlock_folio(folio);
> }
This can be simplified:
1. remove the compound parameter
2. make the if
if (unlikely((vma->vm_flags & (VM_LOCKED|VM_SPECIAL)) == VM_LOCKED) &&
folio_within_vma())
mlock_folio(folio);
> @@ -651,8 +652,12 @@ void munlock_folio(struct folio *folio);
> static inline void munlock_vma_folio(struct folio *folio,
> struct vm_area_struct *vma, bool compound)
Remove the compound parameter here too.
> {
> - if (unlikely(vma->vm_flags & VM_LOCKED) &&
> - (compound || !folio_test_large(folio)))
> + /*
> + * To handle the case that a mlocked large folio is unmapped from VMA
> + * piece by piece, allow munlock the large folio which is partially
> + * mapped to VMA.
> + */
> + if (unlikely(vma->vm_flags & VM_LOCKED))
> munlock_folio(folio);
> }
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 2668f5ea35342..455f415d8d9ca 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -803,6 +803,14 @@ struct folio_referenced_arg {
> unsigned long vm_flags;
> struct mem_cgroup *memcg;
> };
> +
> +static inline bool should_restore_mlock(struct folio *folio,
> + struct vm_area_struct *vma, bool pmd_mapped)
> +{
> + return !folio_test_large(folio) ||
> + pmd_mapped || folio_within_vma(folio, vma);
> +}
This is just folio_within_vma() :)
> /*
> * arg: folio_referenced_arg will be passed
> */
> @@ -816,13 +824,25 @@ static bool folio_referenced_one(struct folio *folio,
> while (page_vma_mapped_walk(&pvmw)) {
> address = pvmw.address;
>
> - if ((vma->vm_flags & VM_LOCKED) &&
> - (!folio_test_large(folio) || !pvmw.pte)) {
> - /* Restore the mlock which got missed */
> - mlock_vma_folio(folio, vma, !pvmw.pte);
> - page_vma_mapped_walk_done(&pvmw);
> - pra->vm_flags |= VM_LOCKED;
> - return false; /* To break the loop */
> + if (vma->vm_flags & VM_LOCKED) {
> + if (should_restore_mlock(folio, vma, !pvmw.pte)) {
> + /* Restore the mlock which got missed */
> + mlock_vma_folio(folio, vma, !pvmw.pte);
> + page_vma_mapped_walk_done(&pvmw);
> + pra->vm_flags |= VM_LOCKED;
> + return false; /* To break the loop */
> + } else {
There is no need for "else", or just
if (!folio_within_vma())
goto dec_pra_mapcount;
> + /*
> + * For large folio cross VMA boundaries, it's
> + * expected to be picked by page reclaim. But
> + * should skip reference of pages which are in
> + * the range of VM_LOCKED vma. As page reclaim
> + * should just count the reference of pages out
> + * the range of VM_LOCKED vma.
> + */
> + pra->mapcount--;
> + continue;
> + }
> }
next prev parent reply other threads:[~2023-07-12 6:24 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-12 6:01 [RFC PATCH v2 0/3] support large folio for mlock Yin Fengwei
2023-07-12 6:01 ` [RFC PATCH v2 1/3] mm: add functions folio_in_range() and folio_within_vma() Yin Fengwei
2023-07-12 6:11 ` Yu Zhao
2023-07-12 6:01 ` [RFC PATCH v2 2/3] mm: handle large folio when large folio in VM_LOCKED VMA range Yin Fengwei
2023-07-12 6:23 ` Yu Zhao [this message]
2023-07-12 6:43 ` Yin Fengwei
2023-07-12 17:03 ` Yu Zhao
2023-07-13 1:55 ` Yin Fengwei
2023-07-14 2:21 ` Hugh Dickins
2023-07-14 2:49 ` Yin, Fengwei
2023-07-14 3:41 ` Hugh Dickins
2023-07-14 5:45 ` Yin, Fengwei
2023-07-12 6:01 ` [RFC PATCH v2 3/3] mm: mlock: update mlock_pte_range to handle large folio Yin Fengwei
2023-07-12 6:31 ` Yu Zhao
2023-07-15 6:06 ` Yu Zhao
2023-07-16 23:59 ` Yin, Fengwei
2023-07-17 0:35 ` Yu Zhao
2023-07-17 1:58 ` Yin Fengwei
2023-07-18 22:48 ` Yosry Ahmed
2023-07-18 23:47 ` Yin Fengwei
2023-07-19 1:32 ` Yosry Ahmed
2023-07-19 1:52 ` Yosry Ahmed
2023-07-19 1:57 ` Yin Fengwei
2023-07-19 2:00 ` Yosry Ahmed
2023-07-19 2:09 ` Yin Fengwei
2023-07-19 2:22 ` Yosry Ahmed
2023-07-19 2:28 ` Yin Fengwei
2023-07-19 14:26 ` Hugh Dickins
2023-07-19 15:44 ` Yosry Ahmed
2023-07-20 12:02 ` Yin, Fengwei
2023-07-20 20:51 ` Yosry Ahmed
2023-07-21 1:12 ` Yin, Fengwei
2023-07-21 1:35 ` Yosry Ahmed
2023-07-21 3:18 ` Yin, Fengwei
2023-07-21 3:39 ` Yosry Ahmed
2023-07-20 1:52 ` Yin, Fengwei
2023-07-17 8:12 ` Yin Fengwei
2023-07-18 2:06 ` Yin Fengwei
2023-07-18 3:59 ` Yu Zhao
2023-07-26 12:49 ` Yin Fengwei
2023-07-26 16:57 ` Yu Zhao
2023-07-27 0:15 ` Yin Fengwei
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=CAOUHufZQ0EpyRZ_jAMxs8uNSQOz6uAkzVjvvgD+4wBvmgHJoCA@mail.gmail.com \
--to=yuzhao@google.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=fengwei.yin@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryan.roberts@arm.com \
--cc=shy828301@gmail.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