linux-kernel - Re: [RFC PATCH 1/1] mm: mark folio accessed in minor fault

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOUHufajdi7LjyJWNoDx7RP_i9mmN8j9dBqO7GC4A6YNPNnygw@mail.gmail.com>
Date: Wed, 20 Dec 2023 23:32:35 -0700
From: Yu Zhao <yuzhao@...gle.com>
To: Zhaoyang Huang <huangzhaoyang@...il.com>
Cc: Matthew Wilcox <willy@...radead.org>, "zhaoyang.huang" <zhaoyang.huang@...soc.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, steve.kang@...soc.com
Subject: Re: [RFC PATCH 1/1] mm: mark folio accessed in minor fault

On Wed, Dec 20, 2023 at 11:28 PM Zhaoyang Huang <huangzhaoyang@...il.com> wrote:
>
> On Thu, Dec 21, 2023 at 12:53 PM Yu Zhao <yuzhao@...gle.com> wrote:
> >
> > On Wed, Dec 20, 2023 at 9:09 PM Matthew Wilcox <willy@...radead.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@...radead.org> wrote:
> > > > >
> > > > > On Wed, Dec 20, 2023 at 06:29:48PM +0800, zhaoyang.huang wrote:
> > > > > > From: Zhaoyang Huang <zhaoyang.huang@...soc.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?

> 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.