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 5A5F31DF980 for ; Sun, 4 Jan 2026 18:14:44 +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=1767550485; cv=none; b=jc9+g4nUti/22fXkgbvcvUhqsuI5nxHL4GIkbIZxplIl2cBaUaXUdjoFj2fC/RySTJxh6NBZTuCTtwmlv3G5mQlO7iGBot/SZ+x7NtJm2YWOcsKvgJyulLj5Qdqwyl0glLb2P+ESQbVIKnSnCJ0A/vKP4inklfgaQOj9cUHKui8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767550485; c=relaxed/simple; bh=uexxpGTRJdOdjecdMSGkGbE8JdVZGYKsGcsnXnMXSSc=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=DRwLwCVGVcidV9Ya/REIw4PuvfMqCFoDnqe5Z8tFnKDiPnIexnQ9vbfo7JqAi2lJl8GnH4SJb763SbbHFQGrTYho8Dl+j20sxH22B8G+pFxKLoQdl/1vuuh3LdEvdk1+rRu+OZ/0C8bIhkTPedvaF/YRKRFXj2VIgjbMioVYjho= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=UC/MCP98; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="UC/MCP98" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A417C4CEF7; Sun, 4 Jan 2026 18:14:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1767550484; bh=uexxpGTRJdOdjecdMSGkGbE8JdVZGYKsGcsnXnMXSSc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=UC/MCP98UsfJ9tekhTU2w51FdkgZBaC73S0T3w5Vfe1JW1JVNXSvBo/gspEotD9AR M6x6lTFqA4Kd+yzrAyUUdG/n9F95nupj3jIyL/98gH56ZKtylj5uDTFlMVPIR4cxRX 4RvivEddpK2EWpYW0qP6IXEOUvWZZLMA0iVma4UQ= Date: Sun, 4 Jan 2026 10:14:43 -0800 From: Andrew Morton To: wujing Cc: Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qiliang Yuan Subject: Re: [PATCH 1/1] mm/page_alloc: auto-tune min_free_kbytes on atomic allocation failure Message-Id: <20260104101443.f10264bc9730de884b52c5a2@linux-foundation.org> In-Reply-To: References: X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Sun, 4 Jan 2026 20:26:52 +0800 wujing wrote: > Introduce a mechanism to dynamically increase vm.min_free_kbytes when > critical atomic allocations (GFP_ATOMIC, order-0) fail. This prevents > recurring network packet drops or other atomic failures by proactively > reserving more memory. Seems like a good idea, however it's very likely that the networking people have looked into this rather a lot. Can I suggest that you engage with them? netdev@vger.kernel.org. > The adjustment doubles min_free_kbytes upon upon failure (exponential backoff), > capped at 1% of total RAM. But no attempt to reduce it again after the load spike has gone away. > Observed failure logs: > [38535641.026406] node 0: slabs: 941, objs: 54656, free: 0 > [38535641.037711] node 1: slabs: 349, objs: 22096, free: 272 > [38535641.049025] node 1: slabs: 349, objs: 22096, free: 272 > > ... > > +static void boost_min_free_kbytes_workfn(struct work_struct *work); > +static DECLARE_WORK(boost_min_free_kbytes_work, boost_min_free_kbytes_workfn); > + > void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...) > { > struct va_format vaf; > @@ -4947,6 +4951,10 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, > goto retry; > } > fail: > + /* Auto-tuning: trigger boost if atomic allocation fails */ > + if ((gfp_mask & GFP_ATOMIC) && order == 0) > + schedule_work(&boost_min_free_kbytes_work); > + Probably this should be selectable and tunable via a kernel boot parameter or a procfs tunable. But I suggest you not do that work until having discussed the approach with the networking developers. > warn_alloc(gfp_mask, ac->nodemask, > "page allocation failure: order:%u", order); > got_pg: