On Fri, Aug 9, 2024 at 9:22 PM David Hildenbrand <david@xxxxxxxxxx> wrote: > > On 09.08.24 11:05, Ryan Roberts wrote: > > On 09/08/2024 09:58, David Hildenbrand wrote: > >> On 09.08.24 10:42, David Hildenbrand wrote: > >>>>> Not sure I fully understand why David prefers to do the unaccounting at > >>>>> free-time though? It feels unbalanced to me to increment when first mapped but > >>>>> decrement when freed. Surely its safer to either use alloc/free or use first > >>>>> map/last map? > >>>>> > >>>>> If using alloc/free isn't there a THP constructor/destructor that prepares the > >>>>> deferred list? (My memory may be failing me). Could we use that? > >>>> > >>>> Additionally, if we wanted to extend (eventually) to track the number of shmem > >>>> and file mthps in additional counters, could we also account using similar folio > >>>> free-time hooks? If not, it might be an argument to account in rmap_unmap to be > >>>> consistent for all? > >>> > >>> Again, see NR_FILE_THPS handling. No rmap over-complication please. > >> > >> ... not to mention that it is non-sensical to only count pageache folios that > >> are mapped to user space ;) > > > > Yes, good point. I'll get back in my box. :) > > Well, it was a valuable discussion! > > anon folios in the swapcache are interesting: they are only "anon" after > we first mapped them (harder to change, but would be possible by using a > NULL mapping maybe, if really worth it; with memdesc that might turn out > interesting). But once they are anon, they will stay anon until actually > reclaimed -> freed. I assume we don’t need to worry about this, as even AnonPages (NR_ANON_MAPPED) in /proc/meminfo also entirely depends on anon pages becoming anon mappings. > > -- > Cheers, > > David / dhildenb > Thanks Barry
