linux-kernel - [RFC v2 0/3] Decoupling large folios dependency on THP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251206030858.1418814-1-p.raghav@samsung.com>
Date: Sat,  6 Dec 2025 04:08:55 +0100
From: Pankaj Raghav <p.raghav@...sung.com>
To: 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>,
	Zi Yan <ziy@...dia.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	"Liam R . Howlett" <Liam.Howlett@...cle.com>,
	Jens Axboe <axboe@...nel.dk>
Cc: 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,
	Pankaj Raghav <p.raghav@...sung.com>
Subject: [RFC v2 0/3] Decoupling large folios dependency on THP

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