Received-SPF: pass (google.com: domain of linux-kernel+bounces-72458-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240219141703.3851-1-lipeifeng@oppo.com> <20240219141703.3851-2-lipeifeng@oppo.com>
 <7c648dac-3198-3dba-0a96-34798cfdbd99@oppo.com> <CAGsJ_4xPDUgcYxNu230QC--ZiKV71nJJ+v0LVR7yF1io+TiLdA@mail.gmail.com>
 <8ea640a1-fc2c-a6fa-cf4b-bb8c0b694b4f@oppo.com>
In-Reply-To: <8ea640a1-fc2c-a6fa-cf4b-bb8c0b694b4f@oppo.com>
From: Barry Song <21cnbao@gmail.com>
Date: Tue, 20 Feb 2024 20:16:08 +1300
Message-ID: <CAGsJ_4zrctJbGZ6EwTJh5PadG_1Vk09Djw8Vd+hzvorq_DMfig@mail.gmail.com>
Subject: Re: [PATCH 1/2] mm/rmap: support folio_referenced to control if
 try_lock in rmap_walk
To: =?UTF-8?B?5p2O5Z+56ZSL?= <lipeifeng@oppo.com>
Cc: akpm@linux-foundation.org, david@redhat.com, osalvador@suse.de, 
	willy@infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, 
	tkjos@google.com, surenb@google.com, gregkh@google.com, v-songbaohua@oppo.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 20, 2024 at 5:00=E2=80=AFPM =E6=9D=8E=E5=9F=B9=E9=94=8B <lipeif=
eng@oppo.com> wrote:
>
>
> =E5=9C=A8 2024/2/20 11:01, Barry Song =E5=86=99=E9=81=93:
> > Hi peifeng,
> >
> > On Tue, Feb 20, 2024 at 2:43=E2=80=AFPM =E6=9D=8E=E5=9F=B9=E9=94=8B <li=
peifeng@oppo.com> wrote:
> >> add more experts from Linux and Google.
> >>
> >>
> >> =E5=9C=A8 2024/2/19 22:17, lipeifeng@oppo.com =E5=86=99=E9=81=93:
> >>> From: lipeifeng <lipeifeng@oppo.com>
> >>>
> >>> The patch to support folio_referenced to control the bevavior
> >>> of walk_rmap, which for some thread to hold the lock in rmap_walk
> >>> instead of try_lock when using folio_referenced.
> > please describe what problem the patch is trying to address,
> > and why this modification is needed in commit message.
>
> Hi Barry=EF=BC=9A
>
> 1. the patch is one of the kshrinkd series patches.

this seems like a bad name for the patchset as nobody knows
what is kshrinkd. maybe something like "asynchronously
reclaim contended folios rather than aging them"?

>
> 2. it is to support folio_referenced to control the bevavior of walk_rmap=
,
>
> kshrinkd would call folio_referenced through shrink_folio_list but it
> doesn't
>
> want to try_lock in rmap_walk during folio_referenced.
>
>
> > btw, who is set rw_try_lock to 0, what is the benefit?
>
> Actually, the current situation is that only shrink_folio_list will set
> try_lock to 1=EF=BC=8C

understood, as you don't want contended folios to be skipped
by scanner any more.

>
> while others will be set to 0 that it would wait for rwsem-lock if
> contened in rmap_walk.

ok. other reclamation threads will still skip contended folios.

As discussed, the patchset really needs detailed data to back up.

Thanks
Barry