Linux filesystem development
 help / color / mirror / Atom feed
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

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox