Re: [PATCH 16/16] selftests/mm: skip khugepaged shmem cases without a PMD page cache folio

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