Re: [PATCH v3] mm/damon/ops-common: prevent migration fallback to non-target nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] alloc_migration_target() overrides non-blocking gfp flags for large folios, causing kdamond to stall in synchronous direct reclaim.
--

--- Patch [1]: [PATCH v3] mm/damon/ops-common: prevent migration fallback to non-target nodes ---
commit 18e8e5ad17abc759ddf7302875cde768864ba912
Author: Jiahui Zhang <jiahuitry@outlook.com>

mm/damon/ops-common: prevent migration fallback to non-target nodes

This commit modifies DAMON's migration target allocation to use __GFP_THISNODE.
This prevents the allocator from silently falling back to other nodes when the
target node is full, which previously caused misleading migration statistics.

> diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c
> index d7d7f100389b0..e59f77eca83b2 100644
> --- a/mm/damon/ops-common.c
> +++ b/mm/damon/ops-common.c
> @@ -312,7 +312,7 @@ static unsigned int __damon_migrate_folio_list(
>  		 * instead of migrated.
>  		 */
>  		.gfp_mask = (GFP_HIGHUSER_MOVABLE & ~__GFP_RECLAIM) |
> -			__GFP_NOMEMALLOC | GFP_NOWAIT,
> +			__GFP_NOMEMALLOC | GFP_NOWAIT | __GFP_THISNODE,

[Severity: High]
This is a pre-existing issue, but does adding __GFP_THISNODE here cause kdamond
to unexpectedly stall in synchronous direct reclaim when migrating large folios?

When migrate_pages() is called, it uses alloc_migration_target() in
mm/migrate.c. For large folios, alloc_migration_target() unconditionally
overrides the non-blocking GFP flags requested by DAMON:

mm/migrate.c:alloc_migration_target() {
	...
	if (folio_test_large(src)) {
		/*
		 * clear __GFP_RECLAIM to make the migration callback
		 * consistent with regular THP allocations.
		 */
		gfp_mask &= ~__GFP_RECLAIM;
		gfp_mask |= GFP_TRANSHUGE;
		order = folio_order(src);
	}
	...
}

Because GFP_TRANSHUGE includes __GFP_DIRECT_RECLAIM, the allocation can block.
Previously, without __GFP_THISNODE, the allocator could fall back to another
node. By enforcing __GFP_THISNODE on a full target node, this forced direct
reclaim will trigger, stalling the kdamond thread and preventing kswapd wakeups.

Could alloc_migration_target() be updated to respect the caller's intent to
not block?

>  		.nid = target_nid,
>  	};
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721135607.251869-1-sj@kernel.org?part=1