Re: [RFC PATCH 1/4] mcpage: add size/mask/shift definition for multiple consecutive page

[Matthew Wilcox <willy@infradead.org>]

On Mon, Jan 09, 2023 at 08:30:43AM -0800, Dave Hansen wrote:
> On 1/9/23 05:24, Matthew Wilcox wrote:
> > On Mon, Jan 09, 2023 at 03:22:29PM +0800, Yin Fengwei wrote:
> >> The idea of the multiple consecutive page (abbr as "mcpage") is using
> >> collection of physical contiguous 4K page other than huge page for
> >> anonymous mapping.
> > This is what folios are for.  You have an interesting demonstration
> > here that shows that moving to larger folios for anonymous memory
> > is worth doing (thank you!) but you're missing several of the advantages
> > of folios by going off and doing your own thing.
> 
> It might not have come across in the changelog and cover letter, but
> Fengwei and the rest of us *totally* agree with you on this.  "Doing
> your own thing" just isn't going to cut it and if this is going to go
> anywhere, it needs to use folios.
> 
> This series is _pure_ RFC and the comments we're interested in is
> whether this demonstration warrants going back and doing it the right
> way (with folios).

Ah, yes, that didn't come across.  In fact, the opposite came across
with this paragraph:

: This series is the first step of mcpage. The furture work can be
: enable mcpage for more components like page cache, swapping etc.
: Finally, most pages in system will be allocated/free/reclaimed
: with mcpage order.

Since the page cache has been using multipage folios in mainline since
March (and in various trees of mine since Feb 2020!), that indicated
to me either a lack of knowledge of folios, or a rejection of the folio
approach.  Happy to hear that's not true!

Most of the results here validate my experience and/or assumptions,
which is good.  I'm more than happy for someone else to take on the
hard work of folio-ising the anon VMAs.  I see the problems to be
solved as:

 - Determining (on a page fault) what the correct allocation size
   is for this process at this time.  We have the readahead code to
   leverage for files, but I don't think we have anything similar for
   anon memory
 - Inserting multiple PTEs when a multi-page folio is found.  This also
   needs to be done for file pages, and maybe that's a good place
   to start.
 - Finding all the places in the anon memory code that assume that
   PageCompound() / PageTransHuge() is the same thing as
   folio_test_pmd_mappable().

There are probably other things that are going to come up, but I think
starting is the important part.  Not everything needs to be done
immediately (#3 before #1, I would think ;-).