On Tue, Aug 15, 2023 at 08:58:24PM +0100, 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 I think this is the best one to go with. Either that or "managed by rmap". That excludes compoud pages which are allocated from vmalloc() (which can be mmaped), page tables, slab, etc. It includes both file and anon folios. I have a handy taxonomy here: https://kernelnewbies.org/MemoryTypes Unfortunately, folio_test_lru() already exists and means something different ("Is this folio on an LRU list"). I fear folio_test_rmap() would have a similar confusion -- "Is this folio currently findable by rmap", or some such. folio_test_rmappable()?
