From: Artem Lytkin <iprintercanon@gmail.com>
To: David Hildenbrand <david@kernel.org>,
Matthew Wilcox <willy@infradead.org>
Cc: Ackerley Tng <ackerleytng@google.com>, Zi Yan <ziy@nvidia.com>,
Kiryl Shutsemau <kas@kernel.org>, Hugh Dickins <hughd@google.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH 0/4] Extend xas_split* to support splitting arbitrarily large entries
Date: Tue, 25 Aug 2026 12:08:27 +0300 [thread overview]
Message-ID: <20260825090827.64550-1-iprintercanon@gmail.com> (raw)
In-Reply-To: <b682a12f-ac03-4032-851a-f4f7ced4ffa0@kernel.org>
On Tue, Aug 25, 2026 at 10:31:34AM +0200, David Hildenbrand (Arm) wrote:
> > IOW is this driven by a real need, or just some completionist thing?
>
> I heard some use cases using 512M THPs on arm64 to back VMs, but it's mostly
> anon pages, and not really ordinary pagecache.
No real need on my side. I took the pagemap.h comment and the selftest
skips as an invitation, and the one 64K user I can find on the list
(Meta, in Kiryl's collapse RFC) says mTHP is what they want. Dropping
the arm64 angle.
> But a buddy-like split is clearly preferable. (or avoiding splitting in the
> first place :) )
That path exists as xas_try_split(). What's left is the uniform split to
order 0 that __folio_split() still does through xas_split_alloc(), and
the only one asking for it past order 11 is guest_memfd. That's
Ackerley's call; if he wants the rebase I'll do the mechanical part.
Artem
prev parent reply other threads:[~2026-08-25 9:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-17 22:46 [RFC PATCH 0/4] Extend xas_split* to support splitting arbitrarily large entries Ackerley Tng
2025-11-17 22:46 ` [RFC PATCH 1/4] XArray: Initialize nodes while splitting instead of while allocating Ackerley Tng
2025-11-17 22:46 ` [RFC PATCH 2/4] XArray: Update xas_split_alloc() to allocate enough nodes to split large entries Ackerley Tng
2025-11-17 22:47 ` [RFC PATCH 3/4] XArray: Support splitting for arbitrarily " Ackerley Tng
2025-11-17 22:47 ` [RFC PATCH 4/4] XArray: test: Increase split order test range in check_split() Ackerley Tng
2025-12-08 3:32 ` Zi Yan
2025-12-08 16:47 ` Ackerley Tng
2025-11-17 23:22 ` [RFC PATCH 0/4] Extend xas_split* to support splitting arbitrarily large entries Matthew Wilcox
2025-11-17 23:43 ` Ackerley Tng
2025-11-18 8:51 ` David Hildenbrand (Red Hat)
2025-12-05 0:38 ` Ackerley Tng
2025-11-18 8:46 ` [syzbot ci] " syzbot ci
2026-08-24 19:47 ` [RFC PATCH 0/4] " Artem Lytkin
2026-08-24 20:31 ` Matthew Wilcox
2026-08-25 8:31 ` David Hildenbrand (Arm)
2026-08-25 9:08 ` Artem Lytkin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260825090827.64550-1-iprintercanon@gmail.com \
--to=iprintercanon@gmail.com \
--cc=ackerleytng@google.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=hughd@google.com \
--cc=kas@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.