Re: [RFC PATCH 0/4] Extend xas_split* to support splitting arbitrarily large entries

[Artem Lytkin <iprintercanon@gmail.com>]

On Mon, Nov 17, 2025 at 02:46:57PM -0800, Ackerley Tng wrote:
> This patch series extends xas_split_alloc() to allocate enough nodes
> for splitting an XArray node beyond 2 levels, and extends xas_split()
> to use the allocated nodes in a split beyond 2 levels.

Ackerley, are you still planning a v2 of this?

I'm asking because there is a second user for it that has nothing to do
with guest_memfd. On arm64 with 64K pages HPAGE_PMD_ORDER is 13 and
MAX_XAS_ORDER is 11, so MAX_PAGECACHE_ORDER clamps to 11 and shmem never
offers a PMD order. MADV_COLLAPSE on tmpfs returns -EINVAL there, and
huge=always hands out order-11 folios at best, so ShmemPmdMapped never
leaves zero. Every other page cache file system tops out at order 11 as
well, which is 128M and not PMD-mappable. pagemap.h admits it outright:
"xas_split_alloc() does not support arbitrary orders. This implies no
512MB THP on ARM64 with 64KB base page size." Kiryl's khugepaged
selftest series skips the shmem and file cases altogether for exactly
this reason, and on 6 August he confirmed in that thread that uniform
splits still go through xas_split_alloc(), so xas_try_split() on its
own does not lift the cap.

That case needs two new levels of nodes rather than one: 130 nodes,
73 KiB, a long way from the 1G to 4K split Matthew was worried about.
Raising MAX_XAS_ORDER to 3 * XA_CHUNK_SHIFT - 1 covers it, and
MAX_PAGECACHE_ORDER stays min()'d with HPAGE_PMD_ORDER, so no page cache
caller can ask for the order-17 worst case that cap admits.

If you would rather not carry the series further, I'd like to pick it
up: rebase on current xarray (2/4 collides with the XA_FLAGS_ACCOUNT
fix, 88f0adba8aa1c, and 3/4 falls over behind it), keep your authorship
on what survives, extend check_split() past order 11, and post it with
the arm64 motivation. Happy either way, I just don't want two of us
rebasing the same patches.

Artem