Re: [PATCH v1 2/2] mm/memory: add anonymous mTHP folios to deferred split list

On Tue, Aug 4, 2026 at 10:39 PM Usama Arif <[email protected]> wrote:
>
>
>
> On 04/08/2026 03:03, Barry Song wrote:
> > On Tue, Aug 4, 2026 at 8:48 AM Johannes Weiner <[email protected]> wrote:
> >>
> > [...]
> >>>
> >>> #define LARGE_FOLIO_ZERO_SCAN_MIN_SIZE SZ_2M
> >>>
> >>> if (folio_size(folio) >= LARGE_FOLIO_ZERO_SCAN_MIN_SIZE)
> >>>      deferred_split_folio(folio, false);
> >>>
> >>> If, someday, people find that 1 MiB also helps, they can provide
> >>> data to support it.
> >>
> >> I am very confused. Did you not see my proposal above?
> >>
> >> Why not this?
> >
> > Hi Johannes,
> >
> > For arm64, if the base page size is 64KB, a PMD would be 512MB,
> > and PMD-1 would be 256MB. Usama mentioned 2MB, which is just
> > order-5, not PMD-1 on arm64.
> >
> > BTW, I assume khugepaged_max_ptes_none is intended for collapse,
> > not splitting. I am a bit concerned that reusing it for this
> > purpose would be quite disruptive.
> >
> We have to use the same parameter for both collapse and splitting.
>
> For example if you use a new parameter for splitting which is set
> higher than the value for collapse, then khugepaged and shrinker
> will constantly thrash each other. khugepaged will collapse
> and shrinker will break it down.

thanks for the clarification, Usama, Johannes.

For your case, where the base page size is 64KB, you want to split
a 2MB mTHP, which is order-5. So would you have
khugepaged_max_ptes_none to 16 (i.e., order-4)?

So, for example, once you have 17 or more zero PTEs, you split the
folio. And if you have 16 or fewer zero PTEs, you collapse it?

If so, it seems Johannes's proposal might be the simplest way to
go.

BTW, do you see any issue around 16? To me, it seems more
sensible to use different thresholds for splitting and collapse,
with the splitting threshold higher than the collapse threshold.
That way, there is some hysteresis between the two, avoiding
thrashing around the threshold.