Messages in this thread | | | Date | Wed, 28 Feb 2024 10:34:04 +0100 | Subject | Re: [PATCH v3 4/4] mm: swap: Swap-out small-sized THP without splitting | From | David Hildenbrand <> |
| |
>>>>> >>>>> To me, it seems safer to split or do some other similar optimization if we find a >>>>> large folio has partial map and unmap. >>>> >>>> I'm hoping that we can avoid any new direct users of _nr_pages_mapped if >>>> possible. >>>> >>> >>> Is _nr_pages_mapped < nr_pages a reasonable case to split as we >>> have known the folio has at least some subpages zapped? >> >> I'm not sure we need this - the folio's presence on the split list will tell us >> everything we need to know I think? > > I agree, this is just one question to David, not my proposal. if > deferred_list is sufficient, > I prefer we use deferred_list. > > I actually don't quite understand why David dislikes _nr_pages_mapped being used > though I do think _nr_pages_mapped cannot precisely reflect how a > folio is mapped > by multi-processes. but _nr_pages_mapped < nr_pages seems be safe to > tell the folio > is partially unmapped :-)
I'm hoping we can get rid of _nr_pages_mapped in some kernel configs in the future (that's what I am working on). So the less we depend on it the better.
With the total mapcount patch I'll revive shortly, _nr_pages_mapped will only be used inside rmap code. I'm hoping we won't have to introduce other users that will be harder to get rid of.
So please, if avoidable, no usage of _nr_pages_mapped outside of core rmap code.
-- Cheers,
David / dhildenb
| |