Received-SPF: pass (google.com: domain of linux-kernel+bounces-82754-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: <CAGsJ_4zera4+bWuXHKjdU3QdiR3sqcUQB3gF08DPD49OCT4S9w@mail.gmail.com>
 <20240226083714.26187-1-ioworker0@gmail.com> <9bcf5141-7376-441e-bbe3-779956ef28b9@redhat.com>
 <CAK1f24mdwjz2J5VmeYSDwb4jMbrXUVCSF_0pOcWSVt1cfa0FhQ@mail.gmail.com>
 <318be511-06de-423e-8216-af869f27f849@arm.com> <CAGsJ_4z+0yXUDYwxKNAqYwxAAYpfKpKd2u_dVTDP3b-KPOQT1g@mail.gmail.com>
 <19758162-be5f-4dc4-b316-77b0115d12ce@intel.com> <CAGsJ_4wx72KOazANBvnGcjdZse8W9+PW5_fspP9=QuX3X_7msg@mail.gmail.com>
 <3c56d7b8-b76d-4210-b431-ee6431775ba7@intel.com> <CAGsJ_4xu1kz5VD-CcNFvP0A1nPKDojV8Gy1HPvNKuQ_RAw=26g@mail.gmail.com>
In-Reply-To: <CAGsJ_4xu1kz5VD-CcNFvP0A1nPKDojV8Gy1HPvNKuQ_RAw=26g@mail.gmail.com>
From: Barry Song <21cnbao@gmail.com>
Date: Tue, 27 Feb 2024 19:42:07 +1300
Message-ID: <CAGsJ_4yAu-m_gYZUSWEGbW4ZMiAPayuZacPN2fYAYXk4Ts_6eg@mail.gmail.com>
Subject: Re: [PATCH 1/1] mm/madvise: enhance lazyfreeing with mTHP in madvise_free
To: Yin Fengwei <fengwei.yin@intel.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>, Lance Yang <ioworker0@gmail.com>, 
	David Hildenbrand <david@redhat.com>, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, 
	linux-mm@kvack.org, mhocko@suse.com, minchan@kernel.org, peterx@redhat.com, 
	shy828301@gmail.com, songmuchun@bytedance.com, wangkefeng.wang@huawei.com, 
	zokeefe@google.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 27, 2024 at 7:40=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot=
e:
>
> On Tue, Feb 27, 2024 at 7:14=E2=80=AFPM Yin Fengwei <fengwei.yin@intel.co=
m> wrote:
> >
> >
> >
> > On 2/27/24 10:17, Barry Song wrote:
> > >> Like if we hit folio which is partially mapped to the range, don't s=
plit it but
> > >> just unmap the mapping part from the range. Let page reclaim decide =
whether
> > >> split the large folio or not (If it's not mapped to any other range,=
it will be
> > >> freed as whole large folio. If part of it still mapped to other rang=
e,page reclaim
> > >> can decide whether to split it or ignore it for current reclaim cycl=
e).
> > > Yes, we can. but we still have to play the ptes check game to avoid a=
dding
> > > folios multiple times to reclaim the list.
> > >
> > > I don't see too much difference between splitting in madvise and spli=
tting
> > > in vmscan.  as our real purpose is avoiding splitting entirely mapped
> > > large folios. for partial mapped large folios, if we split in madvise=
, then
> > > we don't need to play the game of skipping folios while iterating PTE=
s.
> > > if we don't split in madvise, we have to make sure the large folio is=
 only
> > > added in reclaimed list one time by checking if PTEs belong to the
> > > previous added folio.
> >
> > If the partial mapped large folio is unmapped from the range, the relat=
ed PTE
> > become none. How could the folio be added to reclaimed list multiple ti=
mes?
>
> in case we have 16 PTEs in a large folio.
> PTE0 present
> PTE1 present
> PTE2 present
> PTE3  none
> PTE4 present
> PTE5 none
> PTE6 present
> ....
> the current code is scanning PTE one by one.
> while scanning PTE0, we have added the folio. then PTE1, PTE2, PTE4, PTE6=
..
>
> there are all kinds of possibilities for unmapping.
>

not to mention we have all kinds of possibilities like

PTE0 present for large folio1
PTE1 present for large folio1
PTE2 present for another folio2
PTE3 present for another folio3
PTE4 present for large folio1
..

> so what we can do is recording we have added the folio while scanning PTE=
0,
> then skipping this folios for all other PTEs.
>
> otherwise, we can split it while scanning PTE0, then we will meet
> different folios
> afterwards.
>
> >
> >
> > Regards
> > Yin, Fengwei
>
> Thanks
> Barry