Re: Folios for 5.15 request - Was: re: Folio discussion recap -

[Matthew Wilcox]

On Fri, Oct 22, 2021 at 09:59:05AM +0200, David Hildenbrand wrote:
> something like this would roughly express what I've been mumbling about:
> 
> anon_mem    file_mem
>    |            |
>    ------|------
>       lru_mem       slab
>          |           |
>          -------------
>                |
> 	      page
> 
> I wouldn't include folios in this picture, because IMHO folios as of now
> are actually what we want to be "lru_mem", just which a much clearer
> name+description (again, IMHO).

I think folios are a superset of lru_mem.  To enhance your drawing:

page
   folio
      lru_mem
         anon_mem
	 ksm
         file_mem
      netpool
      devmem
      zonedev
   slab
   pgtable
   buddy
   zsmalloc
   vmalloc

I have a little list of memory types here:
https://kernelnewbies.org/MemoryTypes

Let me know if anything is missing.

> Going from file_mem -> page is easy, just casting pointers.
> Going from page -> file_mem requires going to the head page if it's a
> compound page.
> 
> But we expect most interfaces to pass around a proper type (e.g.,
> lru_mem) instead of a page, which avoids having to lookup the compund
> head page. And each function can express which type it actually wants to
> consume. The filmap API wants to consume file_mem, so it should use that.
> 
> And IMHO, with something above in mind and not having a clue which
> additional layers we'll really need, or which additional leaves we want
> to have, we would start with the leaves (e.g., file_mem, anon_mem, slab)
> and work our way towards the root. Just like we already started with slab.

That assumes that the "root" layers already handle compound pages
properly.  For example, nothing in mm/page-writeback.c does; it assumes
everything is an order-0 page.  So working in the opposite direction
makes sense because it tells us what has already been converted and is
thus safe to call.

And starting with file_mem makes the supposition that it's worth splitting
file_mem from anon_mem.  I believe that's one or two steps further than
it's worth, but I can be convinced otherwise.  For example, do we have
examples of file pages being passed to routines that expect anon pages?
Most routines that I've looked at expect to see both file & anon pages,
and treat them either identically or do slightly different things.
But those are just the functions I've looked at; your experience may be
quite different.