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
