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