Re: [PATCH 1/1] mm/page_alloc: auto-tune min_free_kbytes on atomic allocation failure

[Matthew Wilcox]

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

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.