Re: [RFC PATCH] mm: Avoiding split large folios if swap has no space

[Barry Song]

On Fri, Jun 19, 2026 at 7:45 AM Nico Pache <npache@xxxxxxxxxx> wrote:
>
> On Thu, Jun 18, 2026 at 4:17 PM Barry Song (Xiaomi) <baohua@xxxxxxxxxx> wrote:
> >
> > When swap is disabled or exhausted, swap slot allocation
> > may fail during swapout, causing large folios to be split
> > into small folios. The splitting is reasonable when we
> > truly fail to obtain contiguous swap slots, but it is
> > pointless in the no-space case.
>
> Hi Barry,
>
> Are we sure splitting is pointless?  Since b1f202060afe ("mm: remap
> unused subpages to shared zeropage when splitting isolated thp") a
> split can lead to memory reclaim.
>
> I've been far removed from the reclaim code for quite some time but im
> assuming in this case we can actually reclaim some unused memory which
> might be beneficial if there is memory pressure. However there are
> some discussions on whether we should further guard this zeropage
> remapping behavior [1].

Hi Nico,
nice to hear your feedback.

We already have code to split partially unmapped subpages
to reclaim memory before folio_alloc_swap(folio):

                                /*
                                 * Split partially mapped folios right away.
                                 * We can free the unmapped pages without IO.
                                 */
                                if
(data_race(!list_empty(&folio->_deferred_list) &&
                                    folio_test_partially_mapped(folio)) &&
                                    split_folio_to_list(folio, folio_list))
                                        goto activate_locked;

But it seems you are suggesting that we could split even
fully mapped folios, possibly to look for zero-filled
subpages within them?

I feel this only makes sense when there is an actual split
requirement. In cases where we are running out of swap or
swap is unavailable, forcing a split seems incorrect. Even in
a normal mTHP case without swapping involved, an mTHP can
still contain zero-filled subpages.

Recently, we did a number of experiments to relocate
zero-filled pages to zero_pfn by forcing SWAPOUT, and then
mapping them back to zero_pfn during swapin via my previous
RFC - mm: map zero-filled pages to zero_pfn while doing
swap-in[1]. However, we found no improvement in reducing
memory usage, as these zero-filled pages are quite volatile
and are quickly overwritten with non-zero data. So I gave
up efforts to detect zero-filled pages and perform
zero_pfn remapping.

In conclusion, I feel it is not useful to detect zero-filled
subpages, since they are quickly replaced by non-zero data.
In our experiments, we triggered forced SWAPOUT every minute
after detecting zero-filled pages, but found no reduction in
memory usage.

[1] https://lore.kernel.org/linux-mm/20241212073711.82300-1-21cnbao@xxxxxxxxx/

>
> [1] - https://lore.kernel.org/lkml/20260609114619.144416-1-npache@xxxxxxxxxx/

Best Regards
Barry