Re: [LSF/MM/BPF TOPIC] Towards removing CONFIG_PAGE_MAPCOUNT

["David Hildenbrand (Arm)" <david@kernel.org>]

On 2/19/26 18:07, Zi Yan wrote:
> On 17 Feb 2026, at 16:04, David Hildenbrand (Arm) wrote:
> 
>> Hi,
>>
>> although I like mapcounts very much, I'd rather prefer to not have mapcount work on my todo list.
>>
>> We now have CONFIG_NO_PAGE_MAPCOUNT in the kernel that doesn't touch any mapcount values of tail pages, which is great. But we still have CONFIG_PAGE_MAPCOUNT around, being used as default.
>>
>>
>> To make my dream come true, some things I have in mind are still pending. In particular, I want to:
>>
>> (a) Support mapping of folios > PMD through PMDs.
>>
>> (b) Get rid of CONFIG_PAGE_MAPCOUNT to stop messing with
>>      page->_mapcount on tail pages and to cleanup the rmap code.
>>
>> (c) Better detect partially-mapped anon folios with
>>      CONFIG_NO_PAGE_MAPCOUNT.
>>
>> + some other small things.
>>
>>
>> I discussed some of these challenges at LSF/MM 2024 [1], before we had CONFIG_NO_PAGE_MAPCOUNT. No we have it and we can discuss the next steps.
>>
>>
>> Sorting out (a) is fairly easy once we removed CONFIG_PAGE_MAPCOUNT: we'll primarily have to split folio->_entire_mapcount into folio->_pmd_mapcount and folio->_pud_mapcount.
> 
> Then, for PMD sized folio, _pmd_mapcount is its “_entire_mapcount”, for
> PUD sized folio, _pud_mapcount is its “_entire_mapcount”. For mulit-PMD
> or multi-PUD folio, _pmd_mapcount and _pud_mapcount are similar to
> _nr_pages_mapped but with PMD_NR/PUD_NR multiplier. Maybe we would have
> _pte_mapcount instead of _nr_pages_mapped?

What we'd have is essentially (ignoring hugetlb) is

* mapcount
* pmd_mapcount
* pud_mapcount

pte_mapcount = mapcount - pmd_mapcount - pud_mapcount

That is sufficient to calculate folio_average_page_mapcount().

There are some possible evolutions of this concept (but some other stuff 
would have to change), but above is what we would start with.

> 
>>
>> Sorting out (b) requires switching to CONFIG_NO_PAGE_MAPCOUNT first, which will imply some imprecision with large folios to:
>>
>> (1) Process memory stats: Pss + Uss accounting like "Pss" and "Shared_"
>>      vs "Private_" in /proc/$PID/smaps and /proc/$PID/smaps_rollup
>>
>> (2) PM_MMAP_EXCLUSIVE flag in /proc/$PID/pagemap
>>
>> (3) System memory stats: "mapped" memory like "AnonPages", "Mapped"
>>      and "Shmem" in /proc/meminfo
>>
>> And some other smaller things. While I think that all changes here should be fine, I want to be a bit careful and have a discussion on how to tackle it without realizing in a couple of releases that some use cases still require CONFIG_PAGE_MAPCOUNT.
>>
>> Sorting out (c) is a harder nut to crack, and I wonder to which degree we care and whether I am being too careful. I have some ideas that I want to discuss. One idea is to just remove the deferred split lists and let memory reclaim deal with that:
> 
> Or let a workqueue to walk rmap to check if an unmapped subpage indeed has
> no mapping left and put that folio in deferred_split list. Or let the
> deferred_list_scan does the rmap walk and decide whether to split the folio.

Exactly. That is one solution I had in mind and started prototyping at 
some point after LPC: flag folios as possibly-partially-mapped and let 
deferred splitting figure it out.

-- 
Cheers,

David