On 28.01.23 01:48, Jane Chu wrote:
On 1/26/2023 12:37 AM, David Hildenbrand wrote:
On 25.01.23 23:09, Vishal Moola wrote:
[..]
The issue is that we're not estimating the mapcount of the folio, so the
name is very misleading ... I think you really want to avoid the term
mapcount completely in that context. We're just using the #mappings of
the first subpage to determine something differently.
Thinking about it, I guess "folio_estimated_sharers()" might be what we
actually want to name it. Then you can comment how we estimate sharers
by looking at into how many page tables the first subpage is currently
mapped, and assume the same holds true for the other subpages.
It's unreliable because other subpages might behave differently, we
might not be holding the pagelock to stabilize, and we're not looking at
indirect mappings via the swapcache. But it's a comapratively good
estimate for most scenarios I guess.
Hmm, how about simply call it folio_hpage_mapcount(),
folio_firstpage_mapcount(), or, folio_cover_mapcount() ?
All not better IMHO.
folio_estimated_subpage_mapcount() is a bit too verbose for my taste and ...
It is used to replace page_mapcount() in that sense -
https://lore.kernel.org/linux-mm/Y9MDJuPWsk9820xD@x1n/T/#me0531cfb9e82ad5ca88804c727d69cc6b9b33ffa
if (flags & (MPOL_MF_MOVE_ALL) ||
(flags & MPOL_MF_MOVE && folio_estimated_mapcount(folio) == 1 &&
!hugetlb_pmd_shared(pte))) {
if (isolate_hugetlb(folio, qp->pagelist) &&
... what we want to have here is an estimation on the number of sharers.
[actually, we would want it precise, but that's hard to achieve ... ]
--
Thanks,
David / dhildenb
