linux-kernel - Re: [PATCH 1/1] mm/page_alloc: auto-tune min_free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aVsixmk_D99cZqz5@casper.infradead.org>
Date: Mon, 5 Jan 2026 02:32:38 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: wujing <realwujing@...com>, Vlastimil Babka <vbabka@...e.cz>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Michal Hocko <mhocko@...e.com>,
	Brendan Jackman <jackmanb@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>, Zi Yan <ziy@...dia.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Qiliang Yuan <yuanql9@...natelecom.cn>
Subject: Re: [PATCH 1/1] mm/page_alloc: auto-tune min_free_kbytes on atomic
 allocation failure

On Sun, Jan 04, 2026 at 10:14:43AM -0800, Andrew Morton wrote:
> On Sun,  4 Jan 2026 20:26:52 +0800 wujing <realwujing@...com> 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@...r.kernel.org.

Agreed, the networking people should definitely be brought into this.

I'm broadly in favour of something like this patch.  We should do more
auto-tuning and less reliant on sysadmin intervention.  I have two
questions:

1. Is doubling too aggressive?  Would an increase of, say, 10% or 20%
be more appropriate?

2. Do we have to wait for failure before increasing?  Could we schedule
the increase for when we get to within, say, 10% of the current limit?

> > 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.

Hm, how would we do that?  Automatically decay by 5%, 300 seconds after
increasing; then schedule another decay for 300 seconds after that until
we get down to something appropriately smaller?

> > +	/* 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.

Ugh, please, no new tunables.  Let's just implement an algorithm that
works.