Received-SPF: pass (google.com: domain of linux-kernel+bounces-157989-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240422055213.60231-1-ioworker0@gmail.com> <ZiiHSwG_bnLJbwfb@casper.infradead.org>
 <1a0ca018-8ad3-42b0-b98a-8e6b6862fc7a@redhat.com> <333181FE-C2E6-4859-AF6A-0667A1F42037@nvidia.com>
 <51ba6efa-ce5a-49cf-b90e-62310db2c561@redhat.com>
In-Reply-To: <51ba6efa-ce5a-49cf-b90e-62310db2c561@redhat.com>
From: Lance Yang <ioworker0@gmail.com>
Date: Thu, 25 Apr 2024 12:17:36 +0800
Message-ID: <CAK1f24nb6FkipH3OZa0uwbBWkefS3f2BrJ_GTxkS2j6+6bgODQ@mail.gmail.com>
Subject: Re: [PATCH v2 1/1] mm/vmscan: avoid split PMD-mapped THP during shrink_folio_list()
To: David Hildenbrand <david@redhat.com>
Cc: Zi Yan <ziy@nvidia.com>, Matthew Wilcox <willy@infradead.org>, akpm@linux-foundation.org, 
	maskray@google.com, ryan.roberts@arm.com, 21cnbao@gmail.com, mhocko@suse.com, 
	fengwei.yin@intel.com, zokeefe@google.com, shy828301@gmail.com, 
	xiehuan09@gmail.com, wangkefeng.wang@huawei.com, songmuchun@bytedance.com, 
	peterx@redhat.com, minchan@kernel.org, linux-mm@kvack.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Zi, David,

Thanks for taking time to review!

On Wed, Apr 24, 2024 at 11:58=E2=80=AFPM David Hildenbrand <david@redhat.co=
m> wrote:
>
> On 24.04.24 17:57, Zi Yan wrote:
> > On 24 Apr 2024, at 3:17, David Hildenbrand wrote:
> >
> >> On 24.04.24 06:15, Matthew Wilcox wrote:
> >>> On Mon, Apr 22, 2024 at 01:52:13PM +0800, Lance Yang wrote:
> >>>> When the user no longer requires the pages, they would use
> >>>> madvise(MADV_FREE) to mark the pages as lazy free. IMO, they would n=
ot
> >>>> typically rewrite to the given range.
> >>>>
> >>>> At present, PMD-mapped THPs that are marked as lazyfree during
> >>>> shrink_folio_list() are unconditionally split, which may be unnecess=
ary.
> >>>> If the THP is clean, its PMD is also clean, and there are no unexpec=
ted
> >>>> references, then we can attempt to remove the PMD mapping from it. T=
his
> >>>> change will improve the efficiency of memory reclamation in this cas=
e.
> >>>
> >>> Does this happen outside of benchmarks?  I'm really struggling to see
> >>> how we end up in this situation.  We have a clean THP without swap
> >>> backing, so it's full of zeroes, but for some reason we haven't used =
the
> >>> shared huge zero page?  What is going on?
> >>
> >> It's not full of zeroes.
> >>
> >> User space called MADV_FREE on a PMD-mapped THP.
> >>
> >> During MADV_FREE, we mark the PTEs as clean, the folio as clean and sd=
 "lazyfree" (no swap backend). If, during memory reclaim, we detect that (a=
) the folio is still clean (b) the PTEs are still clean and (c) there are n=
o unexpected references (GUP), user space didn't re-write to that memory ag=
ain, so we can just discard the memory "lazily".
> >
> > It seems that try_to_unmap_one() does not support unmapping PMD-mapped =
folios.
> > Maybe adding that support instead of a special case handling?
>
> I was thinking the same, and finding a way to avoid TTU_LAZYFREE_THP.

Thanks for the suggestions!

Yep, I completely agreed. Adding support for unmapping PMD-mapped folios to
try_to_unmap_one() would make it more future-proof.

Thanks again for the review!
Lance

>
> --
> Cheers,
>
> David / dhildenb
>