From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=34.218.115.239 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794567802; b=2TRZn5MbRTh6HIwXJC5R+nBT0MnsvWIPe96q+8eXcRrw6+/bTXtLtkSA2yzpHC9gBQEV sHsVYuZGmy2zvUkWyHEFTWeDpFa5Z64TEQ/CXcEeRdmEmw5NpFTzj3zZjevIgVOeZqMEG GPNSxh+Ek2Jks1UCLzyx4Q8f2Oj/MSR4rvybQNyUKUZOMUTamaLi2qS+zy6ef6vzUgdKc gsXukZowbvRQshX9dfIB/1D0dB+jf/3ocGd766zec5+R7FwFpR4dnYQdWX9UiZSHCSQmX fSyr/B+KDP0/43jk/G7r+EO77ZlM4K0mNoT/DeeCeB0dCnZNwVS90u0lONk/Lqsl61g== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794567802; h=DMARC-Filter:DKIM-Signature:X-CSE-ConnectionGUID:X-CSE-MsgGUID: X-IronPort-AV:Received:Received:X-Farcaster-Flow-ID:Received:Received: From:To:CC:Subject:Date:Message-ID:X-Mailer:In-Reply-To:References: MIME-Version:X-Originating-IP:X-ClientProxiedBy:Content-Type: Content-Transfer-Encoding; bh=kBr8YA4fmyeQoevzG0PDemh8JNDakDQrN1HqOxrlam4=; b=CU7gWBrjcHaZHX3O7ExKWJBRMDQetUP6K6QYs5ER0geJAuHlupSbgSXuzoIRSIqBpA5J Y0Q8rTMMdCD9b/H4WzvQ+uUvybz+OShIhUT0VBg8hfU8uBEgkfQFH6chMoyk8Mvyqp++M xA2jSVy+2MmX0a2B+bEn2Gato+3IDxWYJBNq+aA40+FtGvs2DiMAXrgdl202CjhVE8gik mqw2C3XBj2bsh+WmJpeG2FEr5Sui8cJSDtJLrtjnQqQR5/FACdZWL6BAhnXNnt4ly0nwp Rs8n26HS+rvWECGP6VwOuOHPpn4ki482G/ZIvTTddVLmAR/jfoRTItit7Ci0OipbKtA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=amazon.it; spf=pass smtp.mailfrom=amazon.it; dkim=pass header.d=amazon.it header.i=@amazon.it header.a=rsa-sha256 header.s=amazoncorp2 header.b=Hiva21tq; arc=none smtp.remote-ip=34.218.115.239 Received: from pdx-out-013.esa.us-west-2.outbound.mail-perimeter.amazon.com (pdx-out-013.esa.us-west-2.outbound.mail-perimeter.amazon.com [34.218.115.239]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 661F2606A331 for ; Fri, 13 Nov 2026 11:03:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 661F2606A331 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.it Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=amazon.it Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=amazon.it header.i=@amazon.it header.a=rsa-sha256 header.s=amazoncorp2 header.b=Hiva21tq DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.it; i=@amazon.it; q=dns/txt; s=amazoncorp2; t=1794567800; x=1826103800; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=kBr8YA4fmyeQoevzG0PDemh8JNDakDQrN1HqOxrlam4=; b=Hiva21tqdIFvymFz1SsW2sY9cuUSsLIdgHqZX+H2nErUsDWuYDoMYP8K y9m1qVhp8xUz3S78oe4fTb/Bur1uB5RhE2cyNal/yBG9MhWLOgiYtQu06 qvjlPTpmwEXsWs3EpLAiKikom9e3X4AMlleMTNEcxsLOtTwnHpktOELLP TLZNbcdHKWHOXaOGZSgcTLWgIci72ReqQJo3sl3xNwfv3/NxSlVQCxdnZ O/Jc4U97a6KNzASe/WbXaJx2e4og+SHTKzW+1HXxFNvtQkDbcGY57p1tO fRpJd0a70tUBFzb8fMnvov2l8TQnb1VW5a9bjH2ApW6oLF6zpuG1Mnukn A==; X-CSE-ConnectionGUID: tHHg/bCfT625U3FgJvHbTg== X-CSE-MsgGUID: 0z+DYYSIR1aoDgwz6qy3iw== X-IronPort-AV: E=Sophos;i="6.27,211,1787011200"; d="scan'208";a="33653046" Received: from ip-10-5-9-48.us-west-2.compute.internal (HELO smtpout.naws.us-west-2.prod.farcaster.email.amazon.dev) ([10.5.9.48]) by internal-pdx-out-013.esa.us-west-2.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2026 11:03:18 +0000 Received: from EX19MTAUWB001.ant.amazon.com [205.251.233.104:23028] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.12.127:2525] with esmtp (Farcaster) id 92b15291-78fe-43d6-bf6a-ed9bae8607bf; Fri, 13 Nov 2026 11:03:17 +0000 (UTC) X-Farcaster-Flow-ID: 92b15291-78fe-43d6-bf6a-ed9bae8607bf Received: from EX19D001UWA001.ant.amazon.com (10.13.138.214) by EX19MTAUWB001.ant.amazon.com (10.250.64.248) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.56; Fri, 13 Nov 2026 11:03:17 +0000 Received: from dev-dsk-dipiets-1b-77b833da.eu-west-1.amazon.com (10.253.66.177) by EX19D001UWA001.ant.amazon.com (10.13.138.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.56; Fri, 13 Nov 2026 11:03:16 +0000 From: Salvatore Dipietro To: CC: , Johannes Weiner , Andrew Morton , Vlastimil Babka , Subject: [PATCH 6.18.y 2/3] mm: page_alloc: remove ALLOC_NON_BLOCK from ALLOC_RESERVES Date: Fri, 13 Nov 2026 11:02:58 +0000 Message-ID: <20261113110259.2901456-3-dipiets@amazon.it> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20261113110259.2901456-1-dipiets@amazon.it> References: <20261113110259.2901456-1-dipiets@amazon.it> X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-ClientProxiedBy: EX19D031UWC001.ant.amazon.com (10.13.139.241) To EX19D001UWA001.ant.amazon.com (10.13.138.214) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Johannes Weiner [ Upstream commit fe21f930d1e64d121191673076fc4ebe79fc82d5 ] 1ebbb21811b7 ("mm/page_alloc: explicitly define how __GFP_HIGH non-blocking allocations accesses reserves") stopped handing out reserve access for ALLOC_NON_BLOCK on its own: the extra 25% below the min watermark is now only granted on top of ALLOC_MIN_RESERVE. But the flag was left in ALLOC_RESERVES, which produces something odd: With the ALLOC_RESERVES match, __zone_watermark_unusable_free() doesn't subtract the free highatomic pages for them. So in the slowpath, they get to consume regular blocks below the min watermark by the number of free highatomic pages. The highatomic reserve is capped at 1% of the zone, which on any decently sized machine is a multiple of the min watermark: GFP_NOWAIT can drain regular memory to zero. The user-visible result is brutal hiccups during bursts of GFP_NOWAIT allocations under memory pressure. This was found in review and reproduced with a synthetic burst, not observed in production, but the sequence of events is a realistic one: On a 32G box with an anonymous working set, swap, and a filled 290M highatomic reserve, a GFP_NOWAIT burst drove regular free memory in the 28G Normal zone (min=60M) to 28M, 0.8M and 0.6M in three runs. Swapout failed to allocate its swap table, reclaim scanned 13M pages to reclaim 200k, page faults stalled for tens to hundreds of milliseconds. The machine survives it, but not by design: direct reclaimers eventually fail and start unreserving highatomic blocks, until the allocation succeeds or the reserve is gone and the OOM killer runs. That reserve exists for high-order atomic allocations; here it is destroyed to bail out a GFP_NOWAIT consumer that was never entitled to the memory. Remove ALLOC_NON_BLOCK from ALLOC_RESERVES. With that, the GFP_NOWAIT burst is stopped short at the min watermark. No direct reclaim, no stalls, no failed allocations, and the highatomic reserve stays intact for the requests it exists for. __zone_watermark_ok() is unaffected, since everything it keys on ALLOC_NON_BLOCK is already nested under ALLOC_MIN_RESERVE. Update the flag comments accordingly: ALLOC_NON_BLOCK just means the caller can't block; the reserve math belongs with ALLOC_MIN_RESERVE. GFP_ATOMIC order-0 requests have a milder version of the same problem. Through ALLOC_MIN_RESERVE they also count the free highatomic pages in their watermark check, but rmqueue_buddy() serves them regular pages first and only falls back to the reserve once those are gone. They can still push regular free memory to 37.5% of min minus the free highatomic pages before the reserve is touched. Unlike GFP_NOWAIT they are entitled to the reserve, so this needs the watermark check and the freelist order reworked together, and is left to a separate patch. Link: https://lore.kernel.org/20261028171719.2043421-3-hannes@cmpxchg.org Fixes: 1ebbb21811b7 ("mm/page_alloc: explicitly define how __GFP_HIGH non-blocking allocations accesses reserves") Signed-off-by: Johannes Weiner Signed-off-by: Andrew Morton Acked-by: Balbir Singh Reviewed-by: Vlastimil Babka (SUSE) Cc: Matthew Wilcox (Oracle) Cc: Salvatore Dipietro Cc: Christoph Hellwig Cc: Dave Chinner Cc: Matt Fleming Cc: Mel Gorman Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Brendan Jackman Cc: Zi Yan Cc: [ Salvatore: backport to 6.18.y: mm/page_alloc.h does not exist in this tree, the ALLOC_* flags live in mm/internal.h. No code changes. ] --- mm/internal.h | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/mm/internal.h b/mm/internal.h index 47f16afa892a..dbd6e3a0b990 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -1292,12 +1292,11 @@ unsigned int reclaim_clean_pages_from_list(struct zone *zone, #define ALLOC_OOM ALLOC_NO_WATERMARKS #endif -#define ALLOC_NON_BLOCK 0x10 /* Caller cannot block. Allow access - * to 25% of the min watermark or - * 62.5% if __GFP_HIGH is set. - */ +#define ALLOC_NON_BLOCK 0x10 /* Caller cannot block. */ #define ALLOC_MIN_RESERVE 0x20 /* __GFP_HIGH set. Allow access to 50% - * of the min watermark. + * of the min watermark, or 62.5% if + * the caller cannot block either + * (ALLOC_NON_BLOCK). */ #define ALLOC_CPUSET 0x40 /* check for correct cpuset */ #define ALLOC_CMA 0x80 /* allow allocations from CMA areas */ @@ -1311,7 +1310,7 @@ unsigned int reclaim_clean_pages_from_list(struct zone *zone, #define ALLOC_KSWAPD 0x800 /* allow waking of kswapd, __GFP_KSWAPD_RECLAIM set */ /* Flags that allow allocations below the min watermark. */ -#define ALLOC_RESERVES (ALLOC_NON_BLOCK|ALLOC_MIN_RESERVE|ALLOC_HIGHATOMIC|ALLOC_OOM) +#define ALLOC_RESERVES (ALLOC_MIN_RESERVE|ALLOC_HIGHATOMIC|ALLOC_OOM) /* Flags that mean GFP_ATOMIC */ #define ALLOC_MASK_ATOMIC (ALLOC_NON_BLOCK|ALLOC_MIN_RESERVE) -- 2.50.1 AMAZON DEVELOPMENT CENTER ITALY SRL, viale Monte Grappa 3/5, 20124 Milano, Italia, Registro delle Imprese di Milano Monza Brianza Lodi REA n. 2504859, Capitale Sociale: 10.000 EUR i.v., Cod. Fisc. e P.IVA 10100050961, Societa con Socio Unico