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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 8/24/26 22:31, Matthew Wilcox wrote:
> On Mon, Aug 24, 2026 at 10:47:55PM +0300, Artem Lytkin wrote:
>> 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.
> 
> But why would you want it?  With 64KiB pages on arm64, you need 512MiB
> for a PMD-sized page, and that's just too big for current hardware.
> What's your bandwidth?  40GB per DIMM?  With 8 DIMMs, that's an
> aggregate of 320GB bandwidth, so that restricts you to 640 page faults
> per second.  That's too few for almost all workloads.
> 
> The page allocator also isn't great at doing order-13 allocations.

I heard some use cases using 512M THPs on arm64 to back VMs, but it's mostly
anon pages, and not really ordinary pagecache.

> 
> Since arm64 does support 2MiB TLBs, even with a 512MiB PMD size, I'm
> not sure there's a huge performance win waiting for you on the other
> side of all this work.
> 
> IOW is this driven by a real need, or just some completionist thing?
> 
>> 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.
> 
> 130 nodes is still a lot to ask the slab allocator for!  With 64KiB
> pages it's not too bad -- you get 112 per page.  But still ...

IMHO it would be nice if we could just support such splits.

I've always been thinking of it like this: you end up consuming the exact same
memory if you wouldn't have allocated THPs in the first place.

But a buddy-like split is clearly preferable. (or avoiding splitting in the
first place :) )

-- 
Cheers,

David