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

[Zi Yan <ziy@nvidia.com>]

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?

>
> 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.

> but that one might be discussed in another session I'll propose around the deferred split lists.
>
>
> [1] https://lwn.net/Articles/1013649/
>
> -- 
> Cheers,
>
> David


Best Regards,
Yan, Zi