[LSF/MM/BPF TOPIC] Towards removing CONFIG_PAGE_MAPCOUNT

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

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/

-- 
Cheers,

David