All of lore.kernel.org
 help / color / mirror / Atom feed
From: "黄朝阳 (Zhaoyang Huang)" <zhaoyang.huang@unisoc.com>
To: Yu Zhao <yuzhao@google.com>, Zhaoyang Huang <huangzhaoyang@gmail.com>
Cc: "Matthew Wilcox" <willy@infradead.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"康纪滨 (Steve Kang)" <Steve.Kang@unisoc.com>
Subject: reply: [RFC PATCH 1/1] mm: mark folio accessed in minor fault
Date: Fri, 22 Dec 2023 06:28:42 +0000	[thread overview]
Message-ID: <1703226522421.22653@unisoc.com> (raw)
In-Reply-To: <CAOUHufZYqeTyZ7e_QyHnEuo8V0Z-9BD5XyNsMMx8Xp1eK5aNkQ@mail.gmail.com>


On Thu, Dec 21, 2023 at 10:53 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote:
>
> On Thu, Dec 21, 2023 at 2:33 PM Yu Zhao <yuzhao@google.com> wrote:
> >
> > On Wed, Dec 20, 2023 at 11:28 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote:
> > >
> > > On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@google.com> wrote:
> > > >
> > > > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > > >
> > > > > On Thu, Dec 21, 2023 at 09:58:25AM +0800, Zhaoyang Huang wrote:
> > > > > > On Wed, Dec 20, 2023 at 10:14 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > > > > >
> > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote:
> > > > > > > > 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 do this
> > > > > > > > immidiatly when it is accessed. These will introduce two affections:
> > > > > > > >
> > > > > > > > 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 all file
> > > > > > > faults are handled through filemap_map_pages().  So I must ask, 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 added nine
> > > > > years ago in 2014 by commit f1820361f83d
> > > > >
> > > > > > is to have mapped file pages behave like other pages which could 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 not.
> > > > > 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 set
> > > > 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 minor 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?

sorry for my fault on table generation, resend it, I am trying to present how RFC performs in a page's stat transfer 

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        1st scan(shink_folio_list)       2nd access      2nd scan(shrink_active_list)     3rd can(shrink_folio_list)
mainline                     INA/UNR                    INA/REF                           INA/REF                NA                                     ACT/REF
RFC                           INA/UNR                    INA/REF                           ACT/REF                ACT/REF                           NA
(VM_EXEC)
RFC                           INA/UNR                    INA/REF                           ACT/REF                INA/REF                            DROP
(non VM_EXEC)

(4)
                                  1st access                   2nd access                   3rd access          1st scan(shrink_active_list)   2nd scan(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)

> 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 we
> > > can distinguish them in advance.

  reply	other threads:[~2023-12-22  6:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-20 10:29 [RFC PATCH 1/1] mm: mark folio accessed in minor fault zhaoyang.huang
2023-12-20 14:14 ` Matthew Wilcox
2023-12-21  1:58   ` Zhaoyang Huang
2023-12-21  4:09     ` Matthew Wilcox
2023-12-21  4:53       ` Yu Zhao
2023-12-21  6:28         ` Zhaoyang Huang
2023-12-21  6:32           ` Yu Zhao
2023-12-22  5:53             ` Zhaoyang Huang
2023-12-22  6:14               ` Yu Zhao
2023-12-22  6:28                 ` 黄朝阳 (Zhaoyang Huang) [this message]
2023-12-22  6:45                   ` reply: " Yu Zhao
2023-12-22  8:41                     ` Zhaoyang Huang
2023-12-22  9:41                       ` reply: " 黄朝阳 (Zhaoyang Huang)
2023-12-23  2:41                         ` Yu Zhao
2024-01-02  5:36                           ` Zhaoyang Huang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1703226522421.22653@unisoc.com \
    --to=zhaoyang.huang@unisoc.com \
    --cc=Steve.Kang@unisoc.com \
    --cc=akpm@linux-foundation.org \
    --cc=huangzhaoyang@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.org \
    --cc=yuzhao@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.