On Sun, Aug 02, 2026 at 06:50:36PM -0400, Zi Yan wrote:
> On Sun Aug 2, 2026 at 3:52 PM EDT, Kiryl Shutsemau wrote:
> > From: "Kiryl Shutsemau (Meta)" <[email protected]>
> >
> > The page cache caps folio order at MAX_PAGECACHE_ORDER, and
> > xas_split_alloc() puts that cap below the PMD order where a PMD is 512M --
> > arm64 with 64K base pages, as include/linux/pagemap.h says outright.
> > shmem_huge_global_enabled() then offers no PMD order at all, so
> > MADV_COLLAPSE of a shmem range answers -EINVAL and khugepaged passes over
> > it.
>
> IIRC, after READ_ONLY_THP_FOR_FS is removed, all pagecache folios are
> split using non uniform split, xas_try_split(), so does shmem (except
> shmem in swapcache not splittable). In theory, we can get rid of the
> cap, since xas_try_split() does not split more than one level like
> one can try to make xas_split_alloc() split more than two level (e.g.,
> 512MB to 64KB on arm64 with 64KB base page).
Not really: xas_try_split() is the non-uniform path only. A uniform split
of a pagecache folio still goes through xas_split_alloc(), in
__folio_split():
if (split_type == SPLIT_TYPE_UNIFORM) {
xas_set_order(&xas, folio->index, new_order);
xas_split_alloc(&xas, folio, old_order, gfp);
and __split_unmapped_folio() keeps the two apart for a reason it states
itself:
* uniform split has xas_split_alloc() called before
* irq is disabled to allocate enough memory, whereas
* non-uniform split can handle ENOMEM.
So MAX_PAGECACHE_ORDER is still the limit.
I do not think non-uniform split can simply take over everywhere either.
There are going to be cases when a folio has to be fully dissolved to
order-0.
--
Kiryl Shutsemau / Kirill A. Shutemov
