On Thu, Dec 21, 2023 at 10:53 PM Zhaoyang Huang <huangzhaoyang@xxxxxxxxx> wrote:
>
> On Thu, Dec 21, 2023 at 2:33 PM Yu Zhao <yuzhao@xxxxxxxxxx> wrote:
> >
> > On Wed, Dec 20, 2023 at 11:28 PM Zhaoyang Huang <huangzhaoyang@xxxxxxxxx> wrote:
> > >
> > > On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@xxxxxxxxxx> wrote:
> > > >
> > > > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote:
> > > > > > >
> > > > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote:
> > > > > > > > From: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx>
> > > > > > > >
> > > > > > > > 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.
