On 16.08.23 14:05, Matthew Wilcox wrote:
On Wed, Aug 16, 2023 at 12:12:44PM +0200, David Hildenbrand wrote:
On 16.08.23 05:14, Matthew Wilcox wrote:
* 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()?
But what about hugetlb, they are also remappable? We could have
folio_test_rmappable(), but that would then also better include hugetlb ...
We could do that! Have both hugetlb & huge_memory.c set the rmappable
flag. We'd still know which destructor to call because hugetlb also sets
the hugetlb flag.
Starting at the link you provided, I guess "vmalloc" and "net pool" would
not fall under that category, or would they? (I'm assuming they don't get
mapped using the rmap, so they are "different", and they are not managed by
lru).
Right, neither type of page ends up on the LRU, and neither is added to
rmap.
So I assume we only care about anon+file (lru-managed). Only these are
rmappable (besides hugetlb), correct?
folio_test_lru_managed()
Might be cleanest to describe anon+file that are managed by the lru, just
might not be on a lru list right now (difference to folio_test_lru()).
Something I didn't think about last night is that this flag only
_exists_ for large folios. folio_test_lru_managed() (and
folio_test_rmappable()) both sound like they might work if you call them
on single-page folios, but we BUG if you do (see folio_flags())
I've been also thinking about
"folio_test_normal"
But it only makes sense when "all others (including hugetlb) are the odd
one".
Who's to say slab is abnormal? ;-) But this one also fails to
communicate "only call this on large folios". folio_test_splittable()
does at least communicate that this is related to large folios, although
one might simply expect it to return false for single-page folios rather
than BUG.
folio_test_large_rmappable()?
Sounds good to me. We can then further test if it's hugetlb to rule that
one out.
--
Cheers,
David / dhildenb
