Received-SPF: pass (google.com: domain of linux-kernel+bounces-34805-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20231025144546.577640-1-ryan.roberts@arm.com> <20240118111036.72641-1-21cnbao@gmail.com>
 <20240118111036.72641-6-21cnbao@gmail.com> <58efd8d4-28aa-45d6-b384-7463568b24bb@redhat.com>
In-Reply-To: <58efd8d4-28aa-45d6-b384-7463568b24bb@redhat.com>
From: Barry Song <21cnbao@gmail.com>
Date: Tue, 23 Jan 2024 14:49:08 +0800
Message-ID: <CAGsJ_4zwUpL7LihRBOefg-cmY2mgNjMm-MPkq9VFBdXS_4b=uQ@mail.gmail.com>
Subject: Re: [PATCH RFC 5/6] mm: rmap: weaken the WARN_ON in __folio_add_anon_rmap()
To: David Hildenbrand <david@redhat.com>
Cc: ryan.roberts@arm.com, akpm@linux-foundation.org, linux-mm@kvack.org, 
	linux-kernel@vger.kernel.org, mhocko@suse.com, shy828301@gmail.com, 
	wangkefeng.wang@huawei.com, willy@infradead.org, xiang@kernel.org, 
	ying.huang@intel.com, yuzhao@google.com, surenb@google.com, 
	steven.price@arm.com, Barry Song <v-songbaohua@oppo.com>, 
	Chuanhua Han <hanchuanhua@oppo.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 18, 2024 at 7:54=E2=80=AFPM David Hildenbrand <david@redhat.com=
> wrote:
>
> On 18.01.24 12:10, Barry Song wrote:
> > From: Barry Song <v-songbaohua@oppo.com>
> >
> > In do_swap_page(), while supporting large folio swap-in, we are using t=
he helper
> > folio_add_anon_rmap_ptes. This is triggerring a WARN_ON in __folio_add_=
anon_rmap.
> > We can make the warning quiet by two ways
> > 1. in do_swap_page, we call folio_add_new_anon_rmap() if we are sure th=
e large
> > folio is new allocated one; we call folio_add_anon_rmap_ptes() if we fi=
nd the
> > large folio in swapcache.
> > 2. we always call folio_add_anon_rmap_ptes() in do_swap_page but weaken=
 the
> > WARN_ON in __folio_add_anon_rmap() by letting the WARN_ON less sensitiv=
e.
> >
> > Option 2 seems to be better for do_swap_page() as it can use unified co=
de for
> > all cases.
> >
> > Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> > Tested-by: Chuanhua Han <hanchuanhua@oppo.com>
> > ---
> >   mm/rmap.c | 5 ++++-
> >   1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/rmap.c b/mm/rmap.c
> > index f5d43edad529..469fcfd32317 100644
> > --- a/mm/rmap.c
> > +++ b/mm/rmap.c
> > @@ -1304,7 +1304,10 @@ static __always_inline void __folio_add_anon_rma=
p(struct folio *folio,
> >                * page.
> >                */
> >               VM_WARN_ON_FOLIO(folio_test_large(folio) &&
> > -                              level !=3D RMAP_LEVEL_PMD, folio);
> > +                              level !=3D RMAP_LEVEL_PMD &&
> > +                              (!IS_ALIGNED(address, nr_pages * PAGE_SI=
ZE) ||
> > +                              (folio_test_swapcache(folio) && !IS_ALIG=
NED(folio->index, nr_pages)) ||
> > +                              page !=3D &folio->page), folio);
> >               __folio_set_anon(folio, vma, address,
> >                                !!(flags & RMAP_EXCLUSIVE));
> >       } else if (likely(!folio_test_ksm(folio))) {
>
>
> I have on my todo list to move all that !anon handling out of
> folio_add_anon_rmap_ptes(), and instead make swapin code call add
> folio_add_new_anon_rmap(), where we'll have to pass an exclusive flag
> then (-> whole new folio exclusive).
>
> That's the cleaner approach.
>

one tricky thing is that sometimes it is hard to know who is the first
one to add rmap and thus should
call folio_add_new_anon_rmap.
especially when we want to support swapin_readahead(), the one who
allocated large filio might not
be that one who firstly does rmap.
is it an acceptable way to do the below in do_swap_page?
if (!folio_test_anon(folio))
      folio_add_new_anon_rmap()
else
      folio_add_anon_rmap_ptes()

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

Thanks
Barry