From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 713251339B1 for ; Wed, 18 Feb 2026 01:00:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771376411; cv=none; b=l2059+wPK4jNPrUB16dC03W/+Fpueb7xnarmOACrj/ke/MxJ3lxjqJXft8kgb4K3+ooNDS7PPsqepm9MfAgjVCbCx5CNR4BJ2JHK9434WH4zK9M+LYWKQNMDx6zboUwAZo+gvp0BdAQSdXopW+Do3Rwu/noAtql5jwflB25EBj4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771376411; c=relaxed/simple; bh=Zi/hbrzAQ6HD/Ca/Z25uQVxrxlf0y9pGLZODPBxVeV4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rGTMV3RusQxLbpWKDYwF3EPKkTgdddICTEDwxs+lhc63YqT964rB2dlyf44uRL0iKKaDxiryS/Nm8qamHrLGqemMYIzVqJWDNrT15/vUgPxhFUIxcDUUpFcKLnbQNsijcEUFeqPwTrn00APejqEkxTeVlPT0sfoMmKq/kf4kGhE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XljOV0aE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XljOV0aE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE11BC4CEF7; Wed, 18 Feb 2026 01:00:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771376411; bh=Zi/hbrzAQ6HD/Ca/Z25uQVxrxlf0y9pGLZODPBxVeV4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XljOV0aE04c1d17L8gouamIzQUOv4O9rADZJwPc2FGF3d/Gj7epRYdtPSB/0GlwAE UTXLQpAUFSOEeaos7fYLhARK42ZQq4tZ9rkG1VZyQusapyhjGcEVngQFgiUbqTBJDq FdQ3Ka3hRl3Yg1q/BeNR4PSndOXFRUsNLtc/Oondetrvkk7vBsXhEkPvW7cHEFrJC4 adoMUL/m19u4Ldg3++TgIKNWYauUo5bGh3DJmjuBoIlUrZASYqQxrSIw+8dnacEy/+ E1leP4jjCRMqak+DN/XbfxY3J6A3Do5miMrpKxBeyKo/zofI44tNW7os7b16Ugi2Bw d4UxZoPvveZKA== From: SeongJae Park To: Qiliang Yuan Cc: SeongJae Park , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Axel Rasmussen , Yuanchu Xie , Wei Xu , Brendan Jackman , Johannes Weiner , Zi Yan , Lance Yang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v10] mm/page_alloc: boost watermarks on atomic allocation failure Date: Tue, 17 Feb 2026 16:59:46 -0800 Message-ID: <20260218005947.2979-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260214-wujing-mm-page_alloc-v8-v10-1-bdfea431fd97@gmail.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Sat, 14 Feb 2026 23:13:50 +0800 Qiliang Yuan wrote: > Atomic allocations (GFP_ATOMIC) are prone to failure under heavy memory > pressure as they cannot enter direct reclaim. > > Handle these failures by introducing a watermark boost mechanism for > atomic requests. Refactor boost_watermark() using an internal helper to > support both fragmentation and atomic paths. Apply zone-proportional > boosts (~0.1% of managed pages) for atomic allocations, while > decoupling it from watermark_boost_factor. > > Implement boost_zones_for_atomic() to iterate through and boost all > eligible zones in the zonelist, respecting nodemasks. Use a per-zone > 1-second debounce timer via last_boost_jiffies to prevent excessive > boosting. Protect modifications with zone->lock and verify with > lockdep. Integrate the mechanism into the page allocation slowpath > specifically for order-0 GFP_ATOMIC requests. > > This approach reuses existing infrastructure and ensures emergency > reserves even if fragmentation boosting is disabled. > > Allocation failure logs: > [38535644.718700] node 0: slabs: 1031, objs: 43328, free: 0 > [38535644.725059] node 1: slabs: 339, objs: 17616, free: 317 > [38535645.428345] SLUB: Unable to allocate memory on node -1, gfp=0x480020(GFP_ATOMIC) > [38535645.436888] cache: skbuff_head_cache, object size: 232, buffer size: 256, default order: 2, min order: 0 > [38535645.447664] node 0: slabs: 940, objs: 40864, free: 144 > [38535645.454026] node 1: slabs: 322, objs: 19168, free: 383 > [38535645.556122] SLUB: Unable to allocate memory on node -1, gfp=0x480020(GFP_ATOMIC) > [38535645.564576] cache: skbuff_head_cache, object size: 232, buffer size: 256, default order: 2, min order: 0 > [38535649.655523] warn_alloc: 59 callbacks suppressed > [38535649.655527] swapper/100: page allocation failure: order:0, mode:0x480020(GFP_ATOMIC), nodemask=(null) > [38535649.671692] swapper/100 cpuset=/ mems_allowed=0-1 > > Acked-by: Vlastimil Babka > Signed-off-by: Qiliang Yuan Acked-by: SeongJae Park Thanks, SJ [...]