From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) (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 64A1040800D for ; Tue, 19 May 2026 15:28:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779204528; cv=none; b=t7snESb851o8x+fRvFsdjKCTYW8+Q/0xEPR1G+YiqAi4j8LepK+4UdG04wBX0cUL0pGQtNm89s0esod++8DDzeeoUYwEjwNGFPS2r81IeLvNshQxLQCLFPiCphr/6Lc3AZ2UWbrCehk5oMMRo6I9HY8ISs0mmnXIlNOB+emfwY8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779204528; c=relaxed/simple; bh=YUPdURl4jwnOXAMizy8iHevpBti58t0Jsq8CDEe4GsQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uqNZEXWeOgawY8UMW91JwtEaTNWvyAUc65F22hm1gSKfFbEu3uHqT3OLp2wUn87ssA6vZl4bDRJu71ZdPxrNk0QPHVo/ufwr0YjdJYdVhUE21DLU+fAplR1YY3/IRFT7NWy6xc5vXfv9Op9VOB2vQjBIobew6wWu5jyP+f9Hq6o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=EqBKsd0+; arc=none smtp.client-ip=209.85.221.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="EqBKsd0+" Received: by mail-vk1-f174.google.com with SMTP id 71dfb90a1353d-57747a2bf20so912698e0c.0 for ; Tue, 19 May 2026 08:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1779204525; x=1779809325; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=41IoTmzqXr53RmB6owczF2apNHb2eoFFvybTnR8Tgts=; b=EqBKsd0+qxQcGhXWI4IZ1aOck4IzCy9M0ULlY1wls13Omb5NHO3aqXNM/zRTDBFHgW T3Iuy74a+f/mn2do5ehWMrUSDBetpOycc0p0JdLP5PpuO34ZIsgJc5wgTd3vozbEH79O qd4bUxA/xPT9ruTa3w5MqEDGcB0eBEQ/ykF2yCe8u9impKMubkmIzW7Q8o9wHOtZmlWQ 7ZUACxpw3hsOGAQJA+33avCvkxGUSKckxkq3fFZVBPV4AB8DZX8WA1hOaOgWWT3spkqk +HUAj8XwfFu+I+uBtMjDUFHJFnaHfYSrjm8g/k5zunwheM+c32aGJ3rP9CE3D8tfmzf+ aQQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779204525; x=1779809325; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=41IoTmzqXr53RmB6owczF2apNHb2eoFFvybTnR8Tgts=; b=JvUcrzvrF2Z592N5UAZPmvgP+uwwIMcmzQr14jD8PtyFEg9gzzukdj5T3Adfxv3SgP rPfuLwpfVvpCPfl3UBX7Gk4//0UdgZQDnVdfWIAWd12+COcxIsstHm7PFFq2M3NG4OgU VrKuhpKG0VDJm/+e8TCJcmHVgPT23hAWBVjsUm3JJMJ2UIIAt63RmVOeRpKdZ8ukZwHF 2So3dEWfXE1KdVsQysEZGAf5l0MOC5AFK5KtTlG7gVmbvG4JGrK37OI6SwkX/GdvLP0z 3NRcEdU0NpLsMZ+4gT7vGPd0QMC2JCrCZP842/22+K2RoKB+IPtzFrYdpAmBHjJR9q49 dfsw== X-Forwarded-Encrypted: i=1; AFNElJ/Geyva6YDXfuOd2IXfBzU/GK6aiBfoQt954lA+znkPYLdarC8sG01MSjlucK2NoGDd4BKETsnBzjAL98o=@vger.kernel.org X-Gm-Message-State: AOJu0Yzq8YXbNzAImOYx3ZGxOcllPCilYDsUFYS5JdlDKAq69rHeeTQm S3/iySmBoNGi2f66rnTVcUscncVxS/p45LqryCZBrotSj+e6VCqePUYFkponPtRZ9sA= X-Gm-Gg: Acq92OFX8OCn97tZSs3b4LoOjeWr9AlTXhVjIsSjAbQrq0A/YkW7fdV+Ykcf3Appht2 vhXq3ezrumzHo8oaCM4bbHTjwjEMKdmM+d5PpSeDsvDwIArrzs5WJS878QNvwrqM/1fOYLbfAHn qHaDcqoP8jHi1K781rEnuSD5bTxWUfpwTdqBNymFOHmQcLUriFxE5Pofv/jSAotU0MrMOZVlyEp MbpdrPKzZYI7CWIcvEcUkFcujg1F65DgOaKNRWDVedhfPS93/yjn0RnHVJ4CrZv1FXSWUsaSdq5 QhUBGnsMkob9/ZtoMIdE7N1XDPqLtOP/6oAxMqcuUFM35xd+Y8x6+c6u0N+Jps8Lp1wud1cwcV2 LcnqJvwREphuFZq/Nz23+rcgbanrs+DJQ4hEJAxCTfC8+B7Ujv6BemhRf597TIwE8gvBUcshqjT hechB6vMUkxdGhKzMA95Flhw== X-Received: by 2002:a05:6122:3412:b0:575:33d4:d100 with SMTP id 71dfb90a1353d-5760c08e3b6mr11890452e0c.13.1779204525141; Tue, 19 May 2026 08:28:45 -0700 (PDT) Received: from localhost ([2603:7001:f100:500:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-51645688c13sm166193861cf.1.2026.05.19.08.28.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 08:28:42 -0700 (PDT) Date: Tue, 19 May 2026 11:28:39 -0400 From: Johannes Weiner To: Dmitry Ilvokhin Cc: Andrew Morton , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH] mm/page_alloc: fix defrag_mode for non-reclaimable allocations Message-ID: References: <20260518163736.173910-1-d@ilvokhin.com> <20260518132422.8cfec729a4d7e974c87ace72@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, May 19, 2026 at 01:47:52PM +0000, Dmitry Ilvokhin wrote: > On Mon, May 18, 2026 at 01:24:22PM -0700, Andrew Morton wrote: > > On Mon, 18 May 2026 16:37:36 +0000 Dmitry Ilvokhin wrote: > > > > > When defrag_mode is enabled, ALLOC_NOFRAGMENT is enforced to prevent > > > migratetype fallbacks and keep pageblocks clean. The allocator relies on > > > reclaim and compaction to free pages of the correct type before allowing > > > fallback as a last resort. > > > > > > However, non-reclaimable allocations such as GFP_ATOMIC cannot invoke > > > direct reclaim or compaction. With defrag_mode=1, these allocations hit > > > the !can_direct_reclaim bailout in __alloc_pages_slowpath() with > > > ALLOC_NOFRAGMENT still set, and fail without ever attempting a fallback. > > > > > > This causes a large number of SLUB allocation failures for > > > skbuff_head_cache under network-heavy workloads, despite free memory > > > being available in other migratetype freelists. > > > > > > Clear ALLOC_NOFRAGMENT and retry before giving up on allocations that > > > cannot reclaim, following the same pattern used after reclaim/compaction > > > exhaustion later in the slowpath. > > > > Thanks. Sashiko asked a couple of things: > > > > https://sashiko.dev/#/patchset/20260518163736.173910-1-d@ilvokhin.com > > > > I'm not sure what to make of the first one - we aren't holding any locks > > in there which prevent concurrent cpuset or zonelist alterations > > anyway (?). > > > > But your change might violate the later comment `No "goto retry;" can be > > placed above this check * unless it can execute just once'? > > Thanks for taking a look, Andrew. > > Goto retry can execute at most once, since ALLOC_NOFRAGMENT is cleared > before the jump, so on the next iteration the condition is false and we > fall through to goto nopage. This is the similar to the existing > can_retry_reserves path. Yes, it's just a one-off retry with relaxed fragmentation rules, no need to re-evaluate the cpuset. So this looks fine to me. > Just for the sake of keeping everything in one place. Another point > Sashiko raised. > > "Will allocations hitting this PF_MEMALLOC check, or the __GFP_NORETRY check > further down in the function, still fail prematurely under defrag_mode=1? > Because these terminal error paths also jump directly to the nopage label, > they skip the normal ALLOC_NOFRAGMENT clearing at the bottom of the slowpath. > Should we also clear ALLOC_NOFRAGMENT and retry for these paths so they are > allowed to fall back rather than failing outright?" > > I think by the time we reach the PF_MEMALLOC check, ALLOC_NOFRAGMENT has > already been cleared, since we set only ALLOC_NO_WATERMARKS and > ALLOC_KSWAPD in reserve_flags, when PF_MEMALLOC is set. Yes, that's correct. alloc_flags gets overwritten, losing NOFRAGMENT, for privileged requests. And then we retry with that already. > For GFP_NORETRY, we can do direct reclaim (compared to GFP_ATOMIC case), > so we either succeed or not, we don't need another round. This is an interesting question. GFP_NORETRY can reclaim and compact once, yes, but ALLOC_NOFRAGMENT is still a higher bar, increasing the likelihood of failure. However, unlike GFP_ATOMIC, GFP_NORETRY are usually speculative allocations with reasonable fallback options (like slub's optimistic higher order requests). The idea behind defrag_mode is to not fragment until the alternative is OOM. For GFP_ATOMIC, failing is an OOM-like event. For the other nopage cases, it's more about "my favorite thing isn't available". So I'd say let's fix GFP_ATOMIC and leave the other cases alone unless somebody specifically brings it up as an issue. However, there is one catch: GFP_ATOMIC is not its own flag. You're gating on can_direct_reclaim which is also true for optimistic things like mTHP allocations (GFP_TRANSHUGE_LIGHT e.g.). We don't want to fragment for those, either. So I think you'd want to check at least if __GFP_KSWAPD_RECLAIM is set (which it is for GFP_ATOMIC) to decide between fragmenting and failing. If the caller doesn't even set that, it's a good indicator that they're purely speculative, and failing is the better option. With that, Acked-by: Johannes Weiner