File-backed Large folios were initially implemented with dependencies on Transparent
Huge Pages (THP) infrastructure. As large folio adoption expanded across
the kernel, CONFIG_TRANSPARENT_HUGEPAGE has become an overloaded
configuration option, sometimes used as a proxy for large folio support
[1][2][3].

This series is a part of the LPC talk[4], and I am sending the RFC
series to start the discussion.

There are multiple solutions to solve this problem and this is one of
them with minimal changes. I plan on discussing possible other solutions
at the talk.

Based on my investigation, the only feature large folios depend on is
the THP splitting infrastructure. Either during truncation or memory
pressure when the large folio has to be split, then THP's splitting
infrastructure is used to split them into min order folio chunks.

In this approach, we restrict the maximum order of the large folio to
minimum order to ensure we never use the splitting infrastructure when
THP is disabled.

I disabled THP, and ran xfstests on XFS with 16k, 32k and 64k blocksizes
and the changes seems to survive the test without any issues.

Looking forward to some productive discussion.

P.S: Thanks to Zi, David and willy for all the ideas they provided to
solve this problem.

[1] https://lore.kernel.org/linux-mm/731d8b44-1a45-40bc-a274-8f39a7ae0f7f@lucifer.local/
[2] https://lore.kernel.org/all/aGfNKGBz9lhuK1AF@casper.infradead.org/
[3] https://lore.kernel.org/linux-ext4/20251110043226.GD2988753@mit.edu/
[4] https://lpc.events/event/19/contributions/2139/

Pankaj Raghav (3):
  filemap: set max order to be min order if THP is disabled
  huge_memory: skip warning if min order and folio order are same in
    split
  blkdev: remove CONFIG_TRANSPARENT_HUGEPAGES dependency for LBS devices

 include/linux/blkdev.h  |  5 -----
 include/linux/huge_mm.h | 40 ++++++++--------------------------------
 include/linux/pagemap.h | 17 ++++++-----------
 mm/memory.c             | 41 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 55 insertions(+), 48 deletions(-)


base-commit: e4c4d9892021888be6d874ec1be307e80382f431
-- 
2.50.1

On 5 Dec 2025, at 22:08, Pankaj Raghav wrote:

> File-backed Large folios were initially implemented with dependencies on Transparent
> Huge Pages (THP) infrastructure. As large folio adoption expanded across
> the kernel, CONFIG_TRANSPARENT_HUGEPAGE has become an overloaded
> configuration option, sometimes used as a proxy for large folio support
> [1][2][3].
>
> This series is a part of the LPC talk[4], and I am sending the RFC
> series to start the discussion.
>
> There are multiple solutions to solve this problem and this is one of
> them with minimal changes. I plan on discussing possible other solutions
> at the talk.
>
> Based on my investigation, the only feature large folios depend on is
> the THP splitting infrastructure. Either during truncation or memory
> pressure when the large folio has to be split, then THP's splitting
> infrastructure is used to split them into min order folio chunks.
>
> In this approach, we restrict the maximum order of the large folio to
> minimum order to ensure we never use the splitting infrastructure when
> THP is disabled.
>
> I disabled THP, and ran xfstests on XFS with 16k, 32k and 64k blocksizes
> and the changes seems to survive the test without any issues.

But are large folios really created?

IIUC, in do_sync_mmap_readahead(), when THP is disabled, force_thp_readahead
is never set to true and later ra->order is set to 0. Oh, page_cache_ra_order()
later bumps new_order to mapping_min_folio_order(). So large folios are
created there.

I wonder if core-mm should move mTHP code out of CONFIG_TRANSPARENT_HUGEPAGE
and mTHP might just work. Hmm, folio split might need to be moved out of
mm/huge_memory.c in that case. khugepaged should work for mTHP without
CONFIG_TRANSPARENT_HUGEPAGE as well. OK, for anon folios, the changes might
be more involved.

>
> Looking forward to some productive discussion.
>
> P.S: Thanks to Zi, David and willy for all the ideas they provided to
> solve this problem.
>
> [1] https://lore.kernel.org/linux-mm/731d8b44-1a45-40bc-a274-8f39a7ae0f7f@lucifer.local/
> [2] https://lore.kernel.org/all/aGfNKGBz9lhuK1AF@casper.infradead.org/
> [3] https://lore.kernel.org/linux-ext4/20251110043226.GD2988753@mit.edu/
> [4] https://lpc.events/event/19/contributions/2139/
>
> Pankaj Raghav (3):
>   filemap: set max order to be min order if THP is disabled
>   huge_memory: skip warning if min order and folio order are same in
>     split
>   blkdev: remove CONFIG_TRANSPARENT_HUGEPAGES dependency for LBS devices
>
>  include/linux/blkdev.h  |  5 -----
>  include/linux/huge_mm.h | 40 ++++++++--------------------------------
>  include/linux/pagemap.h | 17 ++++++-----------
>  mm/memory.c             | 41 +++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 55 insertions(+), 48 deletions(-)
>
>
> base-commit: e4c4d9892021888be6d874ec1be307e80382f431
> -- 
> 2.50.1


Best Regards,
Yan, Zi

On Tue, Dec 09, 2025 at 11:03:23AM -0500, Zi Yan wrote:
> I wonder if core-mm should move mTHP code out of CONFIG_TRANSPARENT_HUGEPAGE
> and mTHP might just work. Hmm, folio split might need to be moved out of
> mm/huge_memory.c in that case. khugepaged should work for mTHP without
> CONFIG_TRANSPARENT_HUGEPAGE as well. OK, for anon folios, the changes might
> be more involved.

I think this is the key question to be discussed at LPC.  How much of
the current THP code should we say "OK, this is large folio support
and everybody needs it" and how much is "This is PMD (or mTHP) support;
this architecture doesn't have it, we don't need to compile it in".

On 9 Dec 2025, at 23:27, Matthew Wilcox wrote:

> On Tue, Dec 09, 2025 at 11:03:23AM -0500, Zi Yan wrote:
>> I wonder if core-mm should move mTHP code out of CONFIG_TRANSPARENT_HUGEPAGE
>> and mTHP might just work. Hmm, folio split might need to be moved out of
>> mm/huge_memory.c in that case. khugepaged should work for mTHP without
>> CONFIG_TRANSPARENT_HUGEPAGE as well. OK, for anon folios, the changes might
>> be more involved.
>
> I think this is the key question to be discussed at LPC.  How much of

I am not going, so would like to get a summary afterwards. :)

> the current THP code should we say "OK, this is large folio support
> and everybody needs it" and how much is "This is PMD (or mTHP) support;
> this architecture doesn't have it, we don't need to compile it in".

I agree with most of it, except mTHP part. mTHP should be part of large
folio, since I see mTHP is anon equivalent to file backed large folio.
Both are a >0 order folio mapped by PTEs (ignoring to-be-implemented
multi-PMD mapped large folios for now).

Best Regards,
Yan, Zi

On Wed, Dec 10, 2025 at 11:37:51AM -0500, Zi Yan wrote:
> On 9 Dec 2025, at 23:27, Matthew Wilcox wrote:
> 
> > On Tue, Dec 09, 2025 at 11:03:23AM -0500, Zi Yan wrote:
> >> I wonder if core-mm should move mTHP code out of CONFIG_TRANSPARENT_HUGEPAGE
> >> and mTHP might just work. Hmm, folio split might need to be moved out of
> >> mm/huge_memory.c in that case. khugepaged should work for mTHP without
> >> CONFIG_TRANSPARENT_HUGEPAGE as well. OK, for anon folios, the changes might
> >> be more involved.
> >
> > I think this is the key question to be discussed at LPC.  How much of
> 
> I am not going, so would like to get a summary afterwards. :)

You can join the fun at meet.lpc.events, or there's apparently a youtube
stream.

> > the current THP code should we say "OK, this is large folio support
> > and everybody needs it" and how much is "This is PMD (or mTHP) support;
> > this architecture doesn't have it, we don't need to compile it in".
> 
> I agree with most of it, except mTHP part. mTHP should be part of large
> folio, since I see mTHP is anon equivalent to file backed large folio.
> Both are a >0 order folio mapped by PTEs (ignoring to-be-implemented
> multi-PMD mapped large folios for now).

Maybe we disagree about what words mean ;-)  When I said "mTHP" what
I meant was "support for TLB entries which cover more than one page".
I have no objection to supporting large folio allocation for anon memory
because I think that's beneficial even if there's no hardware support
for TLB entries that cover intermediate sizes between PMD and PTE.