Re: [Devel] [PATCH hci-8.1 v2 1/2] mm/memcontrol: allocate numa_migrate targets of the source folio order

[Konstantin Khorenko <khorenko@virtuozzo.com>]

On 10/28/26 16:30, Konstantin Khorenko wrote:
> On 10/28/26 15:22, no-reply@sashiko.virtuozzo.com wrote:
...
>> [Severity: Medium]
>> The order fix looks right, but the no-reclaim, single-node policy is now
>> applied to every large folio, not only PMD-sized THPs.
>>
>> GFP_TRANSHUGE_LIGHT has no __GFP_DIRECT_RECLAIM, and __GFP_THISNODE pins
>> the allocation to ms->current_node. For a small-order file folio or an
>> mTHP, can the allocation now fail on a fragmented node, with no fallback
>> to the other nodes in target_nodes? Before this patch, such folios got an
>> order-0 destination allocated with GFP_HIGHUSER_MOVABLE | __GFP_NORETRY,
>> which does allow direct reclaim.
>>
>> If the allocation fails, migrate_folio_unmap() returns -ENOMEM. In
>> migrate_pages_batch() the -ENOMEM case then does this:
>>
>>     case -ENOMEM:
>>         ...
>>         if (is_large && !nosplit) {
>>             int ret = try_split_folio(folio, split_folios, mode);
>>             ...
>>         }
>>         ...
>>         rc_saved = rc;
>>         if (list_empty(&unmap_folios))
>>             goto out;
>>
>> When the split also fails (for example -EAGAIN from an elevated refcount,
>> or a mapping whose minimum folio order is above 0), migrate_pages()
>> returns a negative value. Then in __memcg_numa_migrate_pages():
>>
>>     ret = migrate_pages(&pages, memcg_numa_migrate_new_folio, ...);
>>     putback_movable_pages(&pages);
>>     if (ret < 0)
>>         return ret;
>>
>> Does this abort the whole memory.numa_migrate write with -ENOMEM and
>> leave the remaining folios of the memcg unmigrated?
>>
>> The old PMD-THP path had the same failure semantics. This patch widens
>> it to all large folio orders, and the commit message doesn't mention the
>> change in allocation policy.
>>
>> Would it be reasonable to fall back to order 0 or to a reclaim-capable
>> gfp mask when the large allocation fails?
> 
> The allocation policy for large folios does not change here. Before
> the patch every folio_test_large() folio already took the
> GFP_TRANSHUGE_LIGHT | __GFP_THISNODE branch, only with HPAGE_PMD_ORDER.
> The order-0 path with reclaim was reached for a large folio only when
> thp_migration_supported() was false, which it never is on x86_64. So a
> fragmented node is now asked for an order-4 folio where it used to be
> asked for an order-9 one.
> 
> The fallback you suggest is in migrate_pages() already. On -ENOMEM
> from the allocator migrate_pages_batch() calls try_split_folio() and
> goes on with the batch, and migrate_pages() then runs the split pieces
> through the same allocator as order-0 folios: GFP_HIGHUSER_MOVABLE |
> __GFP_NORETRY, the whole target nodemask, no __GFP_THISNODE. Only when
> the split fails too does the write return -ENOMEM with the rest
> unmigrated, which is what a PMD THP did before the patch.
> 
> Whether large destinations should drop __GFP_THISNODE and allow direct
> reclaim, as upstream alloc_migration_target() does with GFP_TRANSHUGE
> and the nodemask, is a separate change, not part of this fix.
> 

On the gfp mask for large destinations.

The patch does not change it: large folios took GFP_TRANSHUGE_LIGHT |
__GFP_THISNODE before, only with order 9. Compared with GFP_TRANSHUGE
in upstream alloc_migration_target() it has no direct reclaim (the
allocation is served from the free lists or fails at once, no
compaction either) and no fallback to the other target nodes.

The cost: on a fragmented node the large allocation fails,
migrate_pages() splits the folio and moves the pieces as order-0 pages,
with reclaim and the whole nodemask. The data arrives intact, but as 4K
pages, which the page cache does not grow back. GFP_TRANSHUGE would
keep the folio size more often at the price of a reclaim/compaction
stall in vcmmd, the writer of memory.numa_migrate.

Upstream makes the same choice for the same job: NUMA balancing's
alloc_misplaced_dst_folio() gives large folios exactly
GFP_TRANSHUGE_LIGHT | __GFP_THISNODE. Placement is an optimisation and
should neither reclaim nor land on the wrong node. So I would leave it
unless a two-node host shows NFS or XFS throughput dropping after a VM
migration; the selftest can measure the split rate through
/proc/kpageflags, and then a reclaiming mask is a separate change.



_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel