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

[JP Kobryn (Meta)]

On 4/2/26 6:03 PM, Shakeel Butt wrote:
> On Thu, Apr 02, 2026 at 04:25:11PM -0700, JP Kobryn (Meta) wrote:
> > When kswapd reclaims at high order due to fragmentation,
>
> * kswapd is woken up for the higher order reclaim request
>
> But this can be direct reclaim as well.

Good call.

> > vmpressure() can
> > report poor reclaim efficiency even though the system has plenty of free
> > memory. This is because kswapd scans many pages but finds little to reclaim
> > - the pages are actively in use and don't need to be freed. The resulting
> > scan:reclaim ratio triggers socket pressure, throttling TCP throughput
> > unnecessarily.
> >
> > Net allocations do not exceed order 3 (PAGE_ALLOC_COSTLY_ORDER),
>
> Net not doing costly order allocations is irrelevant here. IIUC you want all
> costly order allocations (like THPs) to not raise vmpressure as those don't
> necessarily represents the memory pressure.

The supporting context I included was based on the investigation that
led to the patch. But as you and Rik both noted, the patch has
greater implications.

> > so high
> > order reclaim difficulty should not trigger socket 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.
> >
> > Signed-off-by: JP Kobryn (Meta) <jp.kobryn@xxxxxxxxx>
>
> The patch looks good. I think we can ask Andrew to just adjust the commit
> message and then you don't need to resend.

It's no problem for me. I'll send a v3 with an updated commit message.