Re: [PATCH mm-unstable v2 1/6] mm: Add folio_estimated_mapcount()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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() ?

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) &&

thanks,
-jane




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux