From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE62E36403A for ; Mon, 3 Aug 2026 09:44:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785750275; cv=none; b=Vn32Vp0lzbBE9grutQGFHnHSP3Sb8crDhefkcK9xep0co6JC1I3C7flGbdFvf4B+xcLxL0rkgGdienSvKKdFoBENQZ5qscPGQ/IdHadUzBSEO3kwVg+qlLIssu4zhaOCjJ3Nifmo1Q0XIkZ/xDVvobWouO2q35au+VwGlXiI0j0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785750275; c=relaxed/simple; bh=Y8TamxoZCGN6xjYPS9FEQJFmFcs3DWaW8N2HsDxCFww=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Z4hPtrc5lnm0y3jPFlkm5vAim/CwFOcPqv25Sj8cUshpPAgwMA6smQ5UjKA/6NdCGbd8yeAKt6llCRaEHiMfc2XrPEe8frJV2eN+W/FHwp4McIdviPdVFv4RDkPnshLjr4NH3XAK+E65W/2G102BjDxs9Pp1ioFhCpwU0fpuxxE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Xmg9Y3uN; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Xmg9Y3uN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAEBB1F000E9; Mon, 3 Aug 2026 09:44:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785750273; bh=KOhYheecQUnFVrVpCgpvGP/7g3mj4mAGi+KSC8/ce0M=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=Xmg9Y3uNj++DUWdqH+KDhGc7xKen49AIQbhB3ronbkhIiJp+Bs/hZoOiESkCNpNyq Gtk5MNuz2HtlX5AtMFSCRi+I0h9qN/w2YKel/+db1aVtrzKiO1slVxPfp36R76zLxn h20v/mUzP91kAiXt6wFZUGoKf83EwIT2GX3+iu1afxMwV1BZpbYG4/CtJ/s1luBM0Y cV4sw8c3v7zUlAQX4bALNahjITbS0Vr3/JlBLenrXC0wLa5vsEJ2P7ZT801KSaiZek /ihkTExc92CeJhOEXKZTnG9gJX7BDH59ig1L+FDhpy2K0kPdNWTkrpHpQ6lWb1u1cy hhzMsTTaB6IAg== Message-ID: <60bd3790-f350-44b4-8066-9e6a7285efff@kernel.org> Date: Mon, 3 Aug 2026 11:44:27 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 24/26] mm/page_alloc: always direct compact for unmapped allocs Content-Language: en-US To: Brendan Jackman , Borislav Petkov , Dave Hansen , Peter Zijlstra , Andrew Morton , David Hildenbrand , Mike Rapoport , Wei Xu , Johannes Weiner , Zi Yan , Lorenzo Stoakes Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, Sumit Garg , Will Deacon , rientjes@google.com, "Kalyazin, Nikita" , patrick.roy@linux.dev, "Itazuri, Takahiro" , Andy Lutomirski , David Kaplan , Thomas Gleixner , Yosry Ahmed , Patrick Bellasi , Reiji Watanabe , Sean Christopherson References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-24-6f5729aa9832@google.com> From: "Vlastimil Babka (SUSE)" Autocrypt: addr=vbabka@kernel.org; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSNWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBrZXJuZWwub3JnPsLBsAQTAQoAWhYhBKlA1DSZLC6OmRA9UCJPp+fM gqZkBQJqFFy6GxSAAAAAAAQADm1hbnUyLDIuNSsxLjEyLDIsMgIbAwUJGtCBUAULCQgHAwUV CgkICwUWAgMBAAIeBQIXgAAKCRAiT6fnzIKmZJIUEADFx/tREzUImHrEwVHeSvDFmA7tJysI UVrlvrM09E7GIuzphzv7jYmo8n3ANpCczLEVr4G0syYQdTigaZgv3+FQDIIzhKih1IHhu1Ei XHlywNWKnQxxQEUNi5Mwx43wQz5XVw9F1A7gtKBKNtfogO511hAbrzagrYajyQacEJ/+sfhZ 9Da8ltHIXD8pcYaHUfQgEusCgmEd9+KrUwrTbckFKmYq5chuE6yJ4J0EmWknL096jIE6CnzF FRslQ3B1UKDjxVsm1ZHfir5NeWszLkTvGFsddFaWTgh8UycESG6VQzKXjjewXu2pG7YQYRpj QKm1W5X2TkwWkXRBZTmfmbhxIUMh3+zf5wQ463rSmDN/8v81tdqBtAW6rH/kzg1GvkaTHXn0 507yEHFzBksk2viAuIxxr7km8+/KARYLIdGtx30EG8cKzAUZOK6WqxtNCsXUJNrVE8CWrCaD icoNu7Fs1c5hmPHdSTnU48ce67449DdnO4neLSNhRiGlMHJgfJUmgrxu/hcYeOZ3haWmEQ2w uW1Mh01OHi8QZHCEyAbABrPs9GUgccc/4eYXX9hIgxfSkYzn8f+8NuIFPWl/0uTvjgqU29FQ SbzOLxHq9439Ox40G5mS5eZXRGxITYR+6TXvRGI6P/264jvflnr/pDGUttaikU+0W+1uxgKH cmYbEc7ATQRbGTU1AQgAn0H6UrFiWcovkh6EXVcl+SeqyO6JHOPm+e9Wu0Vw+VIUvXZVUVVQ La1PQDUi6j00ChlcR66g9/V0sPIcSutacPKfdKYOBvzd4rlhL8rfrdEsQw5ApZxrA8kYZVMh FmBRKAa6wos25moTlMKpCWzTH84+WO5+ziCTsTUZASAToz3RdunTD+vQcHj0GqNTPAHK63sf bAB2I0BslZkXkY1RLb/YhuA6E7JyEd2pilZOrIuBGl/5q2qSakgnAVFWFBR/DO27JuAksYnq +aH8vI0xGvwn75KqSk4UzAkDzWSmO4ZHuahKtQgZNsMYV+PGayRBX9b9zbldzopoLBdqHc4n jQARAQABwsF8BBgBCgAmAhsMFiEEqUDUNJksLo6ZED1QIk+n58yCpmQFAmfIHFQFCRYU6J8A CgkQIk+n58yCpmS2PA//bqN1LfcotmArgElsa+0EGZSQlYgK48pm8WAeTXTngudP9IJ4SuKY HR5RNjHcBeqN+Me0zxRqYzRb8nGanHEkDyf4Im8DQM8d6vbyU+FcPmG4skud4kgS1zMHnlVd SXfSIwKC/hKgdHG8aBV7545Lz9X6Iohea+94wneD0aw/hqF+QWewGZhWJriWAZtvEkzNjQOi 4U9F/trLten/x7bpphDSnDMKJtITbtzATT1Dq7o7VpIUK1nCTQALMuMjKCdi8OdU/+V+R3O4 0PXWvX8qrvqYapVbZ+9KqT74FsuB0Ya9uXwgBF2Q6cRuETZk5vqaqKxzqoQZCO8AOz/58j6O 2RHNy/mZEN+7tJ5Tsq42zVJ4jxsT8b9YplavCMsnBgDeRWhcbYhCyttoL7nYISyWg4kQYZ/P wIV3OuNv2f8iKYsxNsRuClOAF82+gvqOy1/1pprFjy8uo2pkoOrb63aOP3vO5VHnRKgra6dq NcaZ+c6J4H+nEJGi2SkHAUJz5oBzuThvPudLvPA/SK8sKoM01IRxSihev/S/5WLazXB1PGem OCbvzC1IjWJJraxiDJ5IygokapUa2RP7+WBR22skQ3SSl6G107QgWKSyTOGWEaRmV53vxQLV jXuCmzSSasTL60zq5yGrT4/DYQVSNEUiUbG4pYekxJujNeEDkUlky0Y= In-Reply-To: <20260726-page_alloc-unmapped-v3-24-6f5729aa9832@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 7/27/26 00:22, Brendan Jackman wrote: > This is the minimal solution for ensuring that compaction can service > unmapped allocations. Without this, it's possible for compaction to just > check watermarks and see plenty of free pages, without being aware of > the direct map state, and thereby cause an ALLOC_UNMAPPED allocation to > fail unnecessarily. > > Instead, with this change, promote compact_order to pageblock order for > unmapped allocations, much like defrag_mode. Then, check specifically in > compaction for the presence of wholly mapped blocks that can be unmapped > once direct compact is complete. > > This all takes advantage of a major simplification: since unmapped > blocks are currently always unmovable, this can be asymmetric. There is > never a need to promote a !ALLOC_UNMAPPED allocation to compacting at > pageblock_order, because compaction would be trying to generate a > currently-unmapped block to map; that will always fail because it would > require migrating unmapped pages, which is not supported at the moment. > > Signed-off-by: Brendan Jackman Reviewed-by: Vlastimil Babka (SUSE) Nit: > --- > mm/compaction.c | 22 ++++++++++++++++++---- > mm/page_alloc.c | 9 +++++++++ > 2 files changed, 27 insertions(+), 4 deletions(-) > > diff --git a/mm/compaction.c b/mm/compaction.c > index ed12d2fc6fad3..fe1aaf293bbce 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -2531,12 +2531,25 @@ bool compaction_zonelist_suitable(struct alloc_context *ac, int order, > static enum compact_result > compaction_suit_allocation_order(struct zone *zone, unsigned int order, > int highest_zoneidx, unsigned int alloc_flags, > - bool async, bool kcompactd) > + bool unmapped, bool async, bool kcompactd) Instead of the new bool parameter, can we check alloc_flags for ALLOC_UNMAPPED? > { > unsigned long free_pages; > unsigned long watermark; > > - if (kcompactd && defrag_mode) > + /* > + * When trying to generate an unmapped block, check the counter for > + * direct-mapped blocks specifically, since we'll need to unmap the > + * whole block to service the allocation. > + * > + * Why doesn't this apply to the other way around too? (Mightn't we need > + * to _map_ a whole block, to service a !ALLOC_UNMAPPED allocation?) No, > + * because of a likely-temporary simplification: currently, unmapped > + * blocks never contain movable pages, so compaction isn't going to free > + * up one of those. > + */ > + if (unmapped) > + free_pages = zone_page_state(zone, NR_FREE_PAGES_BLOCKS_MAPPED); > + else if (kcompactd && defrag_mode) > free_pages = zone_free_pages_blocks(zone); > else > free_pages = zone_page_state(zone, NR_FREE_PAGES); > @@ -2599,6 +2612,7 @@ compact_zone(struct compact_control *cc, struct capture_control *capc) > ret = compaction_suit_allocation_order(cc->zone, cc->order, > cc->highest_zoneidx, > cc->alloc_flags, > + freetype_unmapped(cc->freetype), > cc->mode == MIGRATE_ASYNC, > !cc->direct_compaction); > if (ret != COMPACT_CONTINUE) > @@ -3084,7 +3098,7 @@ static bool kcompactd_node_suitable(pg_data_t *pgdat) > ret = compaction_suit_allocation_order(zone, > pgdat->kcompactd_max_order, > highest_zoneidx, alloc_flags, > - false, true); > + false, false, true); > if (ret == COMPACT_CONTINUE) > return true; > } > @@ -3127,7 +3141,7 @@ static void kcompactd_do_work(pg_data_t *pgdat) > > ret = compaction_suit_allocation_order(zone, > cc.order, zoneid, cc.alloc_flags, > - false, true); > + false, false, true); > if (ret != COMPACT_CONTINUE) > continue; > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index d12ce84662ab7..5f1dea7eee15b 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -827,6 +827,9 @@ compaction_capture(struct capture_control *capc, struct page *page, > capc_mt != MIGRATE_MOVABLE) > return false; > > + if (freetype_flags(freetype) != freetype_flags(capc->freetype)) > + return false; > + > if (migratetype != capc_mt) > trace_mm_page_alloc_extfrag(page, capc->order, order, > capc_mt, migratetype); > @@ -4523,6 +4526,12 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order, > if ((alloc_flags & ALLOC_NOFRAGMENT) && > free_to_migratetype(ac->freetype) != MIGRATE_MOVABLE) > compact_order = max(order, pageblock_order); > + /* > + * Unmapped allocations benefit from compaction even at order 0, because the > + * allocator will actually grab a whole block. > + */ > + if (freetype_flags(ac->freetype) & FREETYPE_UNMAPPED) > + compact_order = max(order, pageblock_order); > > if (!compact_order) > return NULL; >