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

[Michal Hocko <mhocko@suse.com>]

On Mon 05-01-26 15:29:04, wujing wrote:
> Hi Lance,
> 
> Thanks for the suggestion about using watermark_scale_factor instead of 
> min_free_kbytes. I appreciate the feedback, and I'd like to explain why I 
> believe min_free_kbytes is the correct knob to tune for this specific problem.
> 
> ## The Core Issue
> 
> The failures we're observing are GFP_ATOMIC, order-0 allocations in interrupt 
> context (network packet reception). From the logs:
> 
>   [38535649.655527] swapper/100: page allocation failure: order:0, mode:0x480020(GFP_ATOMIC)
> 
> These allocations:
> 1. Cannot sleep or wait for memory reclaim
> 2. Can only use memory below the MIN watermark (the emergency reserve)
> 3. Fail when even this emergency reserve is exhausted
> 
> ## Why watermark_scale_factor Won't Help
> 
> watermark_scale_factor controls the distance between MIN and LOW watermarks. 
> It makes kswapd wake up earlier (at LOW instead of closer to MIN), which is 
> great for preventing memory pressure.
> 
> However, for GFP_ATOMIC allocations:
> - They don't wait for kswapd
> - They only care about the MIN watermark itself
> - A larger LOW-MIN gap doesn't increase the atomic reserve
> 
> Even if kswapd wakes up 10 seconds earlier due to a higher 
> watermark_scale_factor, network interrupt bursts happen in milliseconds, 
> leaving no time for reclaim.

The thing is that your approach is not immediate anyway. You are
scheduling a deferred work when allocation already fails unless I am
missing something. Which is too late as well.

Lance has a good point that updating the scale factor earlier might help
to smooth out the reclaim for the increased demand.

> ## Why min_free_kbytes Is Necessary
> 
> min_free_kbytes directly controls the MIN watermark — the actual memory 
> reserved for atomic allocations. Increasing it immediately makes more memory 
> available for GFP_ATOMIC, which is what we need.

Well, if the memory is hard to reclaim for kswapd and earlier wake up
doesn't help out to reclaim any memory then is realistic to expect that
direct reclaimers can do better on the min_free_kbytes (and watermarks)
update?

> ## Alternative: Hybrid Approach?
> 
> That said, your point about side effects is valid. One option could be:
> 1. Increase min_free_kbytes for immediate relief during failures
> 2. Also increase watermark_scale_factor slightly to make kswapd more aggressive
> 3. This could reduce the frequency of hitting MIN in the first place
> 
> Would this hybrid approach address your concerns?

I would much rather start with a simpler approach and only make this
more complicated when it turns insufficient. Scaling watermark_scale_factor 
seems like a more natural approach to me. Could you give it a try or
have you tried and it proved to be a worse solution?
-- 
Michal Hocko
SUSE Labs