Re: [RFC PATCH v2] mm: Improve pgdat_balanced() to avoid over-reclamation for higher-order allocation

[Lian Wang <lianux.mm@gmail.com>]

From: "Lian Wang (ProcessMission)" <lianux.mm@gmail.com>

Hi Baolin,

Thanks, this gives us a concrete server-side reproducer. We can set up the
fragmented-memory test with one workload requesting THP and another periodically
accessing file folios through fio. We will keep free memory sufficient for
order-0 allocations so that the test isolates fragmentation-driven reclaim,
then measure fio latency and throughput together with kswapd reclaim, kcompactd
activity, direct reclaim/compaction, and THP allocation success.

We previously reproduced the kswapd CPU and reclaim behavior that motivated
Barry's proposal, but we have not yet measured the benefit or possible
regressions of the patch itself. As Johannes pointed out earlier, limiting
high-order reclaim too aggressively can regress sustained or concurrent huge
page requests by moving more work into direct reclaim and compaction. Therefore,
when testing Barry's patch, we would like to cover both the fio interference
case you described and concurrent higher-order allocation pressure.

Let's also wait for Johannes's thoughts, especially on whether bounding
`sc->nr_to_reclaim` should be combined with better accounting of outstanding
higher-order demand. In parallel, we can align the test matrix around:

  - best-effort order-3 network allocations with immediate order-0 fallback
    on phones;
  - order-3 scarcity with sufficient free memory and repeated kswapd wakeups
    on PCs and VMs;
  - fragmented THP allocations competing with file-folio I/O on servers.

We can run the baseline and Barry's patch with the same reclaim, compaction,
allocation-success, CPU, and workload-latency measurements. This should help us
unify the design discussion and avoid optimizing the phone, PC, or server case
at the expense of the others.

Thanks,
Lian

On Tue, 15 Sep 2026 10:30:50 +0800 Baolin Wang <baolin.wang@linux.alibaba.com> wrote:

> In such fragmentation scenarios, I don't think we should reclaim a large
> number of file folios, instead we should wake up kcompactd to perform
> defragmentation. So in theory, I prefer Barry's earlier proposal to
> adjust 'sc->nr_to_reclaim' [2]. But let's see what Johannes thinks.
>
> Based on our problem, I think we can setup a simple test scenario: one
> workload tries to allocate THP under fragmentation (and free memory was
> sufficient now), while another fio workload accesses file folios
> periodically. In this scenario, kswapd's reclaim should not affect the
> fio workload's performance.
>
> [2]
> https://lore.kernel.org/all/CAGsJ_4x9vkv2G7d-gANf8kqUJVxQh_P9=AJxr98LFUgQeOTqow@mail.gmail.com/