Re: [PATCH v3 3/3] mm/vmscan: don't demote if there is not enough free memory in the lower memory tier

[Gregory Price <gourry@gourry.net>]

On Tue, Jan 27, 2026 at 11:28:59PM +0000, Bing Jiao wrote:
> Hi, Gregory, hope you are doing well.
> 
> I observed that during the allocation of a large folio,
> alloc_migration_target() cleans __GFP_RECLAIM but subsequently applies
> GFP_TRANSHUGE. Given that GFP_TRANSHUGE includes __GFP_DIRECT_RECLAIM,
> I am wondering if this triggers a form of reclamation that should be
> avoided during demotion.
> 
> struct folio *alloc_migration_target(struct folio *src, unsigned long private)
> ...
> 	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);
> 	}
> 
> #define GFP_TRANSHUGE	(GFP_TRANSHUGE_LIGHT | __GFP_DIRECT_RECLAIM)
> 

I think the answer is that the demotion code is a mess and no one
actually knows what it's doing.  We probably need to rework this
entirely because we've now found at least 2 paths which clean and then
add reclaim.

~Gregory