Received-SPF: pass (google.com: domain of linux-kernel+bounces-9391-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20231220102948.1963798-1-zhaoyang.huang@unisoc.com>
 <ZYL2rbD5UTz3s8gg@casper.infradead.org> <CAGWkznFcMkkqsKJSyHJfts9ZiYsxxg_dFTccieQ4+boRDJgG4g@mail.gmail.com>
 <ZYO6bLcCRYlo290g@casper.infradead.org> <CAOUHufZ-hAAB+9iL3K-YokN4oVJoiC9dVQ+6zLu-M4Ag52TY5g@mail.gmail.com>
 <CAGWkznGUvPeWkjcy42dudx_+n19dr7SU3B3GGO6JovXHB-Vyzg@mail.gmail.com>
 <CAOUHufajdi7LjyJWNoDx7RP_i9mmN8j9dBqO7GC4A6YNPNnygw@mail.gmail.com> <CAGWkznFb2vn_+2ho7BQ1cqVDx0cyFzoffS3_nk4hYUNuRSsVGw@mail.gmail.com>
In-Reply-To: <CAGWkznFb2vn_+2ho7BQ1cqVDx0cyFzoffS3_nk4hYUNuRSsVGw@mail.gmail.com>
From: Yu Zhao <yuzhao@google.com>
Date: Thu, 21 Dec 2023 23:14:28 -0700
Message-ID: <CAOUHufZYqeTyZ7e_QyHnEuo8V0Z-9BD5XyNsMMx8Xp1eK5aNkQ@mail.gmail.com>
Subject: Re: [RFC PATCH 1/1] mm: mark folio accessed in minor fault
To: Zhaoyang Huang <huangzhaoyang@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>, "zhaoyang.huang" <zhaoyang.huang@unisoc.com>, 
	Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, 
	linux-kernel@vger.kernel.org, steve.kang@unisoc.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 21, 2023 at 10:53=E2=80=AFPM Zhaoyang Huang <huangzhaoyang@gmai=
l.com> wrote:
>
> On Thu, Dec 21, 2023 at 2:33=E2=80=AFPM Yu Zhao <yuzhao@google.com> wrote=
:
> >
> > On Wed, Dec 20, 2023 at 11:28=E2=80=AFPM Zhaoyang Huang <huangzhaoyang@=
gmail.com> wrote:
> > >
> > > On Thu, Dec 21, 2023 at 12:53=E2=80=AFPM Yu Zhao <yuzhao@google.com> =
wrote:
> > > >
> > > > On Wed, Dec 20, 2023 at 9:09=E2=80=AFPM Matthew Wilcox <willy@infra=
dead.org> wrote:
> > > > >
> > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote:
> > > > > > On Wed, Dec 20, 2023 at 10:14=E2=80=AFPM Matthew Wilcox <willy@=
infradead.org> wrote:
> > > > > > >
> > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrot=
e:
> > > > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> > > > > > > >
> > > > > > > > Inactive mapped folio will be promoted to active only when =
it is
> > > > > > > > scanned in shrink_inactive_list, while the vfs folio will d=
o this
> > > > > > > > immidiatly when it is accessed. These will introduce two af=
fections:
> > > > > > > >
> > > > > > > > 1. NR_ACTIVE_FILE is not accurate as expected.
> > > > > > > > 2. Low reclaiming efficiency caused by dummy nactive folio =
which should
> > > > > > > >    be kept as earlier as shrink_active_list.
> > > > > > > >
> > > > > > > > I would like to suggest mark the folio be accessed in minor=
 fault to
> > > > > > > > solve this situation.
> > > > > > >
> > > > > > > This isn't going to be as effective as you imagine.  Almost a=
ll file
> > > > > > > faults are handled through filemap_map_pages().  So I must as=
k, what
> > > > > > > testing have you done with this patch?
> > > > > > >
> > > > > > > And while you're gathering data, what effect would this patch=
 have on your
> > > > > > > workloads?
> > > > > > Thanks for heads-up, I am out of date for readahead mechanism. =
My goal
> > > > >
> > > > > It's not a terribly new mechanism ... filemap_map_pages() was add=
ed nine
> > > > > years ago in 2014 by commit f1820361f83d
> > > > >
> > > > > > is to have mapped file pages behave like other pages which coul=
d be
> > > > > > promoted immediately when they are accessed. I will update the =
patch
> > > > > > and provide benchmark data in new patch set.
> > > > >
> > > > > Understood.  I don't know the history of this, so I'm not sure if=
 the
> > > > > decision to not mark folios as accessed here was intentional or n=
ot.
> > > > > I suspect it's entirely unintentional.
> > > >
> > > > It's intentional. For the active/inactive LRU, all folios start
> > > > inactive. The first scan of a folio transfers the A-bit (if it's se=
t
> > > > during the initial fault) to PG_referenced; the second scan of this
> > > > folio, if the A-bit is set again, moves it to the active list. This
> > > > way single-use folios, i.e., folios mapped for file streaming, can =
be
> > > > reclaimed quickly, since they are "demoted" rather than "promoted" =
on
> > > > the second scan. This RFC would regress memory streaming workloads.
> > > Thanks. Please correct me if I am wrong. IMO, there will be no
> > > minor-fault for single-use folios
> >
> > Why not? What prevents a specific *access pattern* from triggering mino=
r faults?
> Please find the following chart for mapped page state machine
> transfication.

I'm not sure what you are asking me to look at -- is the following
trying to illustrate something related to my question above?

> We can find that:
> 1. RFC behaves the same as the mainline in (1)(2)
> 2. VM_EXEC mapped pages are activated earlier than mainline which help
> improve scan efficiency in (3)(4)
> 3. none VM_EXEC mapped pages are dropped as vfs pages do during 3rd scan.
>
> (1)
>                                   1st access
> shrink_active_list              1st scan(shink_folio_list)
> 2nd scan(shrink_folio_list')
> mainline                     INA/UNR                        NA
>                           INA/REF
> DROP
> RFC                           INA/UNR                        NA
>                            INA/REF
> DROP
>
> (2)
>                                   1st access                   2nd
> access                        shrink_active_list          1st
> scan(shink_folio_list)
> mainline                     INA/UNR                     INA/UNR
>                       NA                                 ACT/REF
> RFC                           INA/UNR                     INA/REF
>                         NA                                 ACT/REF
>
> (3)
>                                   1st access
> shrink_active_list        1st scan(shink_folio_list)       2nd access
>       2nd scan(shrink_active_list)     3rd scan(shink_folio_list)
> mainline                     INA/UNR                        NA
>                           INA/REF                           INA/REF
>                 NA                                     ACT/REF
> RFC                           INA/UNR                        NA
>                            INA/REF                           ACT/REF
>                 ACT/REF                           NA
> (VM_EXEC)
> RFC                           INA/UNR                        NA
>                            INA/REF                           ACT/REF
>                 INA/REF                            DROP
> (non VM_EXEC)
>
> (4)
>                                   1st access                   2nd
> access                         3rd access
> shrink_active_list                   shink_folio_list
> mainline                     INA/UNR                       INA/UNR
>                        INA/UNR                          NA
>                            ACT/REF
> RFC                           INA/UNR                       INA/REF
>                          ACT/REF                         ACT/REF
>                        NA
> (VM_EXEC)
> RFC                           INA/UNR                       INA/REF
>                          ACT/REF                         ACT/REF
>                        NA
> (Non VM_EXEC)
> >
> > > which means RFC could behave the
> > > same as mainline does now? I think it doesn't make sense to have
> > > multiple-mapped pages filled in page_list to shrink_page_list since w=
e
> > > can distinguish them in advance.