[RFC PATCH] mm/page_alloc: Add PCP list for THP CMA

[Zi Yan]

On 25 Jul 2025, at 3:04, David Hildenbrand wrote:

> On 25.07.25 07:08, akash.tyagi wrote:
>> Hi David,
>>
>> Thank you for your feedback.
>>
>> We encountered this issue in the Android Common Kernel (version 6.12), which uses PCP lists for CMA pages.
>>
>> page_owner trace-
>> Page allocated via order 9, mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 1, tgid 1 (swapper/0), ts 1065952310 ns
>> PFN 0x23d200 type Unmovable Block 4585 type CMA Flags 0x4000000000000040(head|zone=1|kasantag=0x0)
>>   post_alloc_hook+0x228/0x230
>>   prep_new_page+0x28/0x148
>>   get_page_from_freelist+0x19d0/0x1a38
>>   __alloc_pages_noprof+0x1b0/0x440
>>   ___kmalloc_large_node+0xb4/0x1ec
>>   __kmalloc_large_node_noprof+0x2c/0xec
>>   __kmalloc_node_noprof+0x39c/0x548
>>   __kvmalloc_node_noprof+0xd8/0x18c
>>   nf_ct_alloc_hashtable+0x64/0x108
>>   nf_nat_init+0x3c/0xf8
>>   do_one_initcall+0x150/0x3c0
>>   do_initcall_level+0xa4/0x15c
>>   do_initcalls+0x70/0xc0
>>   do_basic_setup+0x1c/0x28
>>   kernel_init_freeable+0xcc/0x130
>>   kernel_init+0x20/0x1ac
>>  This UNMOVABLE page was allocated from CMA, but it could not be migrated - so CMA alloc failed
>> At first, we fixed this by adding CMA THP pages to the movable THP PCP list.
>> This fixed the issue of CMA pages being put in the wrong list, but now any movable allocation can use these CMA pages.
>>
>> Later, we saw that a movable allocation used a CMA page and was pinned by __filemap_get_folio(). This page was pinned for too long, and eventually, CMA allocation failed
>>
>> page_owner trace-
>> Page allocated via order 0, mask 0x140c48(GFP_NOFS|__GFP_COMP|__GFP_HARDWALL|__GFP_MOVABLE), pid 1198, tgid 1194 (ccci_mdinit), ts 17918751965 ns
>> PFN 0x207233 type Movable Block 4153 type CMA Flags 0x4020000000008224(referenced|lru|workingset|private|zone=1|kasantag=0x0)
>>   post_alloc_hook+0x23c/0x254
>>   prep_new_page+0x28/0x148
>>   get_page_from_freelist+0x19d8/0x1a40
>>   __alloc_pages_noprof+0x1a8/0x430
>>   __folio_alloc_noprof+0x14/0x5c
>>   __filemap_get_folio+0x1bc/0x430
>>   bdev_getblk+0xd4/0x294
>>   __read_extent_tree_block+0x6c/0x260
>>   ext4_find_extent+0x22c/0x3dc
>>   ext4_ext_map_blocks+0x88/0x173c
>>   ext4_map_query_blocks+0x54/0xe0
>>   ext4_map_blocks+0xf8/0x518
>>   _ext4_get_block+0x70/0x188
>>   ext4_get_block+0x18/0x24
>>   ext4_block_write_begin+0x154/0x62c
>>   ext4_write_begin+0x20c/0x630
>> Page has been migrated, last migrate reason: compaction
>> Charged to memcg /
>>
>>
>> Currently, free_unref_page treats CMA pages as movable. So, some MOVABLE allocations may use these CMA pages and pinned them. Later, when CMA needs these pages, these pages failed to migrate.
>
>
> MOVABLE allocations commonly fallback to CMA allocations, independent of pcp.
>
> Long-term pinning is forbidden on MIGRATE_CMA pages. We had a bug recently fixed,
> maybe you ran into that?
>
> See
>
> commit 517f496e1e61bd169d585dab4dd77e7147506322
> Author: David Hildenbrand <david at redhat.com>
> Date:   Wed Jun 11 15:13:14 2025 +0200
>
>     mm/gup: revert "mm: gup: fix infinite loop within __get_longterm_locked"
>         After commit 1aaf8c122918 ("mm: gup: fix infinite loop within
>     __get_longterm_locked") we are able to longterm pin folios that are not
>     supposed to get longterm pinned, simply because they temporarily have the
>     LRU flag cleared (esp.  temporarily isolated).
>         For example, two __get_longterm_locked() callers can race, or
>     __get_longterm_locked() can race with anything else that temporarily
>     isolates folios.
>
> But there is this known problem that CMA can fail temporarily due to
> short-term pinnings. See the "reliable CMA" work (don't remember the exact name).
I think you mean Guaranteed CMA[1].

[1] https://lore.kernel.org/linux-mm/CAJuCfpEWVEqsivd7oTvp4foEho_HaD1XNP8KTeKWzG_X2skfGQ@mail.gmail.com/

Best Regards,
Yan, Zi