From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ilvokhin.com (mail.ilvokhin.com [178.62.254.231]) (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 A6EFB2745E for ; Tue, 19 May 2026 13:47:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.62.254.231 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779198477; cv=none; b=icITrz635x6p04n7JPrqpGbNTyY+sf6OuGKLNLqBHRFMiRicb9mBTilk0wGSih9Dx0p+CPKkzBGUJeACJpvK1C0KGoCegO9o5UF2TBMSduW+9N4zkHKEQiCmy5VoLS94LvLwJLED6kZeQ+x11uCMKfXBNr63ebrSPRfJAF89Lig= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779198477; c=relaxed/simple; bh=NLe6ZSwjNV/GgVBsT5yzmruDo5Ovomi1jPj7JtgYvZ0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GHTsoAa3B3Mv7ese4XeRDr9z9GT2bj2UB9SXYrzPIy+DZYQYngQVDiQ/VeJIssvheoqg4gghi3I68bV6mddYxM9w9lsis2rwNtVMivnebsIMKjCFWLgIFS+jt81+d4kJsQjUAZ6HXvQuw7dFUbo49KwAMmnAnl/C6Rw/uBW35OM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=ilvokhin.com; spf=pass smtp.mailfrom=ilvokhin.com; dkim=pass (1024-bit key) header.d=ilvokhin.com header.i=@ilvokhin.com header.b=LXZTkNye; arc=none smtp.client-ip=178.62.254.231 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=ilvokhin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ilvokhin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ilvokhin.com header.i=@ilvokhin.com header.b="LXZTkNye" Received: from shell.ilvokhin.com (shell.ilvokhin.com [138.68.190.75]) (Authenticated sender: d@ilvokhin.com) by mail.ilvokhin.com (Postfix) with ESMTPSA id B292FD081C; Tue, 19 May 2026 13:47:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ilvokhin.com; s=mail; t=1779198473; bh=sOX/BuYnD2WUZPt6d/a906G4y5m10XJ9vS/jNpswwX0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=LXZTkNyesDxZZU56WZHQh3LeocgVhhsVYale4kHEt0k3MeVw953RuPWeP7O2iZY0s fxLvE54SvEMbnH/9ZYJcdEZZsI/g4bxrQzRQbU6CjZ6LX1JF9POgI4UMtEmHdllXKh FRMeP4sgnp6FslYkWG2DUPr+kqpGcaZK1Wi2gDe0= Date: Tue, 19 May 2026 13:47:52 +0000 From: Dmitry Ilvokhin To: Andrew Morton Cc: Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , 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: <20260518132422.8cfec729a4d7e974c87ace72@linux-foundation.org> 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. 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. 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.