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.
