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

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

On 2/17/26 22: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.
> 
> 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: but that one might be discussed in another session I'll propose
> around the deferred split lists.
> 
> 
> [1] https://lwn.net/Articles/1013649/
> 

Slides at:
https://share.daveh.de/s/bQsDpD7xigJ6wD8/download?path=&files=LSF_MM%2726_Towards_Removing_CONFIG_PAGE_MAPCOUNT.pdf

-- 
Cheers,

David