From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 CEE9D22DFA4 for ; Tue, 26 May 2026 13:13:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779801194; cv=none; b=Jtkn9NDgUWOUhSSLgXKI14xfWjsTEKkvxvEJWm5Y76eEDikYFk9p2s0fJ4O/TKJrgyGoyup3W2l+kw8SfeKkFvdVPw0ZJgMl9m2NdVlLDVWmpzQV1N1WEPL30louNkletXD52SFkrLexhOjjSk+tsp2y1ARaxYgK2Zzf0opDcaU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779801194; c=relaxed/simple; bh=g62UTdDSITq93BWIRNVDcAPh3PAEX9lEPwIcegiNgdc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kYlH5Xoy7OAY302clJvZ1hnLJXsotkg0XCJ2k8XsK0RyCpz0KEUI7GiWX7w3erTcPc7PIlaZk+OQqccykIaEv8hu6q5LGtfWDxC51eDZeSjlT/YybF8LIDsivt2fhCOkQQv4aO4bLJJga1p6ix7khSwAc/gGl1lKoMGW8GqQs9M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M3/XZUzi; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M3/XZUzi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82DBC1F000E9; Tue, 26 May 2026 13:13:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779801193; bh=Q6FFUN0+s0JG/7DGCWy33kO8G+yPZh0UptGXR8oA9X8=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=M3/XZUzitaumcj1/KnoWZmvdgSRdUerVUHWtOpQ7yjJ9shktx2IW88h69FXGVVjaY 8k4nIov1fxmbgMmfpel6aLZC0xLOjiRntKLQkMVPCcyhc+jMy1LDRY2abpSVJuueFB 7qZI65LexUAeY4fXm6dD0mntx9qy+3+10s8di10Y+JvfkOzGyEnZwqEtKDqrF2mmbt IH2tPqS4izlT3qB33WP8/2V5B+eheGO37bHrEMgDnZQOW2KwDM7NmdB0cimK6rFlb8 sjtVMBMje1aPmGYR0ou1y07Sf9da7o8kSvc6C0/AqShXSg0cIoGSs1iPZUDN0knrns KAf1FIO5ylFcw== Message-ID: <2aedfd17-17e6-4dfe-8ae5-c7342ead708b@kernel.org> Date: Tue, 26 May 2026 15:13:09 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm/page_alloc: fix defrag_mode for non-reclaimable allocations To: Dmitry Ilvokhin , Andrew Morton Cc: Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com References: <20260520122228.201550-1-d@ilvokhin.com> <20260521165910.e7dea6a4e591d66293d2bd47@linux-foundation.org> From: "Vlastimil Babka (SUSE)" Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/22/26 3:05 PM, Dmitry Ilvokhin wrote: > On Thu, May 21, 2026 at 04:59:10PM -0700, Andrew Morton wrote: >> On Wed, 20 May 2026 12:22:28 +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. >> >> That sounds painful. >> >>> Clear ALLOC_NOFRAGMENT and retry for allocations that request kswapd >>> reclaim but cannot do direct reclaim themselves (GFP_ATOMIC). Purely >>> speculative allocations like GFP_TRANSHUGE_LIGHT that don't set >>> __GFP_KSWAPD_RECLAIM are left to fail, since they have reasonable >>> fallbacks and should not cause fragmentation. >> >> How serious is this to our users when running real-world workloads? > > We observed it on a few of the Meta workloads that adopted > defrag_mode=1. Do you (or Johannes) have some observations to share about what motivated those to adopt it, what kind of workloads benefit and how? Because I have no idea who uses this mode and what are the expectations. Thanks, Vlastimil