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: <tencent_8CE8292766552797836FEB198A402CA2CF06@qq.com>
Date: Mon,  5 Jan 2026 15:29:04 +0800
From: wujing <realwujing@...com>
To: Lance Yang <lance.yang@...ux.dev>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	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>,
	wujing <realwujing@...com>
Subject: Re: [PATCH 1/1] mm/page_alloc: auto-tune min_free_kbytes on atomic allocation failure

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.

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

## 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?

Thanks again for the thoughtful review!

Best regards,
Wujing