Message-ID: <64291696-C808-49D0-9F89-6B3B97F58717@nvidia.com>
Date: Tue, 09 Dec 2025 11:03:23 -0500
From: Zi Yan <ziy@...dia.com>
To: Pankaj Raghav <p.raghav@...sung.com>
Cc: Suren Baghdasaryan <surenb@...gle.com>, Mike Rapoport <rppt@...nel.org>,
 David Hildenbrand <david@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
 Michal Hocko <mhocko@...e.com>, Lance Yang <lance.yang@...ux.dev>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>, Dev Jain <dev.jain@....com>,
 Barry Song <baohua@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>,
 Nico Pache <npache@...hat.com>, Vlastimil Babka <vbabka@...e.cz>,
 "Liam R . Howlett" <Liam.Howlett@...cle.com>, Jens Axboe <axboe@...nel.dk>,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 mcgrof@...nel.org, gost.dev@...sung.com, kernel@...kajraghav.com,
 tytso@....edu
Subject: Re: [RFC v2 0/3] Decoupling large folios dependency on THP

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

Powered by blists - more mailing lists