On 15.08.23 21:58, Matthew Wilcox wrote:
On Tue, Aug 15, 2023 at 07:27:26PM +0200, David Hildenbrand wrote:
On 15.08.23 19:06, Matthew Wilcox wrote:
Theree are a lot of counters called THP and TransHuge and other variants
which are exposed to userspace, and the (user) assumption is that this counts
PMD-sized folios. If you grep around for folio_test_pmd_mappable(),
you'll find them. If we have folio_test_thp(), people will write:
if (folio_test_thp(folio))
__mod_lruvec_state(lruvec, NR_SHMEM_THPS, nr);
instead of using folio_test_pmd_mappable().
So if we *really* don't want to use THP to express that we have a page, then
let's see what these pages are:
* can be mapped to user space
* are transparent to most MM-related systemcalls by (un) mapping
them in system page size (PTEs)
* Are managed on the LRU
* Can be dirtied, written back
Right, but at least hugetlb *could* be extended to do that as well (and
even implement swapping). I think the biggest difference is the
transparency/PTE-mapping/unmapping/ ....
That we can split these pages (not PTE-map, but convert from large folio to
small folios) is one characteristic, but IMHO not the main one (and maybe
not even required at all!).
It's the one which distinguishes them from, say, compound pages used for
slab. Or used by device drivers. Or net pagepool, or vmalloc. There's
a lot of compound allocations out there, and the only ones which need
special treatment here are the ones which are splittable.
And my point is that that is an implementation detail I'm afraid.
Instead of splitting the folio into order-0 folios, you could also
migrate off all data to order-0 folios and just free the large folio.
Because splitting only succeeds if there are no other references on the
folio, just like migration.
But let's not get distracted :)
Maybe we can come up with a better term for "THP, but not necessarily
PMD-sized".
"Large folio" is IMHO bad. A hugetlb page is a large folio and not all large
folios can be mapped to user space.
"Transparent large folios" ? Better IMHO.
I think this goes back to Johannes' point many months ago that we need
separate names for some things. He wants to split anon & file memory
apart (who gets to keep the name "folio" in the divorce? what do we
name the type that encompasses both folios and the other one? or do
they both get different names?)
Good question. I remember discussing a type hierarchy back when you
upstreamed folios.
Maybe we would have "file folios" and "anon folios.
Perhaps the key difference between normal compound pages and file/anon
compound pages is that the latter are splittable? So we can name all
of this:
folio_init_splittable()
folio_test_splittable()
folio_fini_splittable()
Maybe that's still too close to an implementation detail, but it's at
least talking about _a_ characteristic of the folio, even if it's not
the _only_ characteristic of the folio.
Maybe folio_init_transparent() ... avoiding the "huge" part of it.
Very open for alternatives. As expressed in other context, we really should
figure this out soon.
Yeah, I'm open to better naming too. At this point in the flow we're
trying to distinguish between compound pages used for slab and compound
pages used for anon/file, but that's not always going to be the case
elsewhere.
Yes. Let me reply to your other mail.
--
Cheers,
David / dhildenb
