Re: [PATCH v4] mm/vmpressure: skip socket pressure for costly order reclaim

[Barry Song <baohua@kernel.org>]

On Tue, Apr 7, 2026 at 3:50 AM JP Kobryn (Meta) <jp.kobryn@linux.dev> wrote:
>
> When reclaim is triggered by high order allocations on a fragmented system,
> vmpressure() can report poor reclaim efficiency even though the system has
> plenty of free memory. This is because many pages are scanned, but few are
> found to actually reclaim - the pages are actively in use and don't need to
> be freed. The resulting scan:reclaim ratio causes vmpressure() to assert
> socket pressure, throttling TCP throughput unnecessarily.
>
> Costly order allocations (above PAGE_ALLOC_COSTLY_ORDER) rely heavily on
> compaction to succeed, so poor reclaim efficiency at these orders does not
> necessarily indicate memory pressure. The kernel already treats this order
> as the boundary where reclaim is no longer expected to succeed and
> compaction may take over.
>
> Make vmpressure() order-aware through an additional parameter sourced from
> scan_control at existing call sites. Socket pressure is now only asserted
> when order <= PAGE_ALLOC_COSTLY_ORDER.
>
> Memcg reclaim is unaffected since try_to_free_mem_cgroup_pages() always
> uses order 0, which passes the filter unconditionally. Similarly,
> vmpressure_prio() now passes order 0 internally when calling vmpressure(),
> ensuring critical pressure from low reclaim priority is not suppressed by
> the order filter.
>
> The patch was motivated by a case of impacted net throughput in production.
> On one affected host, the memory state at the time showed ~15GB available,
> zero cgroup pressure, and the following buddyinfo state:
>
> Order FreePages
> 0:    133,970
> 1:    29,230
> 2:    17,351
> 3:    18,984
> 7+:   0
>
> Using bpf, it was found that 94% of vmpressure calls on this host were from
> order-7 kswapd reclaim.
>
> TCP minimum recv window is rcv_ssthresh:19712.
>
> Before patch:
> 723 out of 3,843 (19%) TCP connections stuck at minimum recv window
>
> After live-patching and ~30min elapsed:
> 0 out of 3,470 TCP connections stuck at minimum recv window
>
> Signed-off-by: JP Kobryn (Meta) <jp.kobryn@linux.dev>
> Reviewed-by: Rik van Riel <riel@surriel.com>
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> Acked-by: Jakub Kicinski <kuba@kernel.org>

This patch looks sensible to me

Reviewed-by: Barry Song <baohua@kernel.org>

This is a one-sided costly order and should be treated as costly for
reclamation. On the other hand, nominally non-costly orders (e.g.,
order-3) can also become costly. I previously raised this issue here:

https://lore.kernel.org/linux-mm/20251013101636.69220-1-21cnbao@gmail.com/

Burst network traffic can make phones heat up.

More recently, with help from Wang Lian and Kunwu Chan (Cc'ed),
we developed a simple model that reliably reproduces this
behavior, where we observe significant CPU utilization by
kswapd due to 3-order burst allocation from the network.

I may revisit this discussion soon.

Best Regards
Barry