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

["JP Kobryn (Meta)" <jp.kobryn@linux.dev>]

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@linux.dev>
> 
> 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.