From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-237.mta0.migadu.com [91.218.175.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 100E0360EF3 for ; Sat, 15 Aug 2026 14:44:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.237 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786805071; cv=none; b=Ss6IXdsG8a0HNsyRfohUb3++98KPCifPAenPqP1hMV+2Mmfh47NXJDHk+hz3T2bq2zhD/5/QLwh1bXKqJKh9Y2+LkC0nOAMeJYCBKjfOfVAKWmxn8g6XtT+nsuZrwBanljyzMqR7wbxayy/XQCHHY8YkSYp0YR9pKqwkyzTE6No= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786805071; c=relaxed/simple; bh=ihwcnUGvpCpT1va2cNKOoueJ4crpL+N4d9Fdxf7d0bQ=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=gouE8qQCENUWMnD7hqNhjYHrLvicFA6Bot0DaIdb+/vIZ+SZPpNNuS5wbZ7oJVGpz7C2e29OfsXz02hG/KosrGrS9MQvsRNiy8qhBnunV+ZkxN+iJC4oTUAD1vuW7jYT7fTCiUrVEOR9gpbvcopc5oFBvL5OwqmbCQ+qoxIuaE0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=UFQWiPiY; arc=none smtp.client-ip=91.218.175.237 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="UFQWiPiY" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=ihwcnUGvpCpT1va2cNKOoueJ4crpL+N4d9Fdxf7d0bQ=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786805068; v=1; x=1787409868; b=UFQWiPiYnWXg9RLDyWIyRVKSpNYTEV+yAy8qHmeQci53th70XiSGBBi44or+5TsY9ixRSFAJ TJc91WE+mEbRtA5oWBtLbmlS2sRrxL+5/wBd/P1KVaIAVNosQIajD38dBs8JtoIIEQr0wE7mH10 cjK/8Bvz1WSicLVyPg9VX2yo= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (77.97.51.77) by smtp.migadu.com with ESMTPS id 93f03fcd28b6c3a6; Sat, 15 Aug 2026 14:44:27 +0000 X-Migadu-Flow: FLOW_OUT Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 15 Aug 2026 15:44:26 +0100 Message-Id: Cc: , , , "Sumit Garg" , "Will Deacon" , , , "Itazuri, Takahiro" , "Andy Lutomirski" , "David Kaplan" , "Thomas Gleixner" , "Yosry Ahmed" , "Patrick Bellasi" , "Reiji Watanabe" , "Sean Christopherson" Subject: Re: [PATCH v3 24/26] mm/page_alloc: always direct compact for unmapped allocs From: "Brendan Jackman" To: "Vlastimil Babka (SUSE)" , "Borislav Petkov" , "Dave Hansen" , "Peter Zijlstra" , "Andrew Morton" , "David Hildenbrand" , "Mike Rapoport" , "Wei Xu" , "Johannes Weiner" , "Zi Yan" , "Lorenzo Stoakes" X-Mailer: aerc 0.21.0 References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-24-6f5729aa9832@google.com> <60bd3790-f350-44b4-8066-9e6a7285efff@kernel.org> In-Reply-To: <60bd3790-f350-44b4-8066-9e6a7285efff@kernel.org> On Mon Aug 3, 2026 at 10:44 AM BST, Vlastimil Babka (SUSE) wrote: > 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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(-) >>=20 >> 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_c= ontext *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_UNM= APPED? Lol, yes. I guess I didn't notice alloc_flags was already there :D