From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: akpm@linux-foundation.org, hughd@google.com
Cc: willy@infradead.org, david@redhat.com,
wangkefeng.wang@huawei.com, 21cnbao@gmail.com,
ryan.roberts@arm.com, ioworker0@gmail.com, da.gomez@samsung.com,
baolin.wang@linux.alibaba.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/6] Support large folios for tmpfs
Date: Thu, 28 Nov 2024 15:40:38 +0800 [thread overview]
Message-ID: <cover.1732779148.git.baolin.wang@linux.alibaba.com> (raw)
Traditionally, tmpfs only supported PMD-sized large folios. However nowadays
with other file systems supporting any sized large folios, and extending
anonymous to support mTHP, we should not restrict tmpfs to allocating only
PMD-sized large folios, making it more special. Instead, we should allow
tmpfs can allocate any sized large folios.
Considering that tmpfs already has the 'huge=' option to control the PMD-sized
large folios allocation, we can extend the 'huge=' option to allow any sized
large folios. The semantics of the 'huge=' mount option are:
huge=never: no any sized large folios
huge=always: any sized large folios
huge=within_size: like 'always' but respect the i_size
huge=advise: like 'always' if requested with madvise()
Note: for tmpfs mmap() faults, due to the lack of a write size hint, still
allocate the PMD-sized large folios if huge=always/within_size/advise is set.
Moreover, the 'deny' and 'force' testing options controlled by
'/sys/kernel/mm/transparent_hugepage/shmem_enabled', still retain the same
semantics. The 'deny' can disable any sized large folios for tmpfs, while
the 'force' can enable PMD sized large folios for tmpfs.
Any comments and suggestions are appreciated. Thanks.
Changes from v2:
- Collect reviewed tags. Thanks.
- Add a new patch to drop fadvise from the docs.
- Drop the 'MAX_PAGECACHE_ORDER' check in shmem_huge_global_enabled(),
per David.
- Update the commit message, per Daniel.
- Rebase on the latest mm-unstable branch.
Changes from v1:
- Add reviewed tag from Barry and David. Thanks.
- Fix building warnings reported by kernel test robot.
- Add a new patch to control the default huge policy for tmpfs.
Changes from RFC v3:
- Drop the huge=write_size option.
- Allow any sized huge folios for 'hgue' option.
- Update the documentation, per David.
Changes from RFC v2:
- Drop mTHP interfaces to control huge page allocation, per Matthew.
- Add a new helper to calculate the order, suggested by Matthew.
- Add a new huge=write_size option to allocate large folios based on
the write size.
- Add a new patch to update the documentation.
Changes from RFC v1:
- Drop patch 1.
- Use 'write_end' to calculate the length in shmem_allowable_huge_orders().
- Update shmem_mapping_size_order() per Daniel.
Baolin Wang (5):
mm: factor out the order calculation into a new helper
mm: shmem: change shmem_huge_global_enabled() to return huge order
bitmap
mm: shmem: add large folio support for tmpfs
mm: shmem: add a kernel command line to change the default huge policy
for tmpfs
docs: tmpfs: drop 'fadvise()' from the documentation
David Hildenbrand (1):
docs: tmpfs: update the large folios policy for tmpfs and shmem
.../admin-guide/kernel-parameters.txt | 7 +
Documentation/admin-guide/mm/transhuge.rst | 72 ++++++---
include/linux/pagemap.h | 16 +-
mm/shmem.c | 150 ++++++++++++++----
4 files changed, 188 insertions(+), 57 deletions(-)
--
2.39.3
next reply other threads:[~2024-11-28 7:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-28 7:40 Baolin Wang [this message]
2024-11-28 7:40 ` [PATCH v3 1/6] mm: factor out the order calculation into a new helper Baolin Wang
2024-11-28 7:40 ` [PATCH v3 2/6] mm: shmem: change shmem_huge_global_enabled() to return huge order bitmap Baolin Wang
2024-11-28 7:40 ` [PATCH v3 3/6] mm: shmem: add large folio support for tmpfs Baolin Wang
2025-04-29 17:44 ` [REGRESSION] " Ville Syrjälä
2025-04-30 6:32 ` Baolin Wang
2025-04-30 11:20 ` Ville Syrjälä
2025-04-30 13:24 ` Daniel Gomez
2025-05-02 1:02 ` Baolin Wang
2025-05-02 7:18 ` David Hildenbrand
2025-05-02 13:10 ` Daniel Gomez
2025-05-02 15:31 ` David Hildenbrand
2025-05-06 3:33 ` Baolin Wang
2025-05-06 14:36 ` David Hildenbrand
2024-11-28 7:40 ` [PATCH v3 4/6] mm: shmem: add a kernel command line to change the default huge policy " Baolin Wang
2024-11-28 7:40 ` [PATCH v3 5/6] docs: tmpfs: update the large folios policy for tmpfs and shmem Baolin Wang
2024-11-28 7:40 ` [PATCH v3 6/6] docs: tmpfs: drop 'fadvise()' from the documentation Baolin Wang
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=cover.1732779148.git.baolin.wang@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=da.gomez@samsung.com \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=ioworker0@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryan.roberts@arm.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).