All of lore.kernel.org
 help / color / mirror / Atom feed
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: [RFC PATCH v3 0/4] Support large folios for tmpfs
Date: Thu, 10 Oct 2024 17:58:10 +0800	[thread overview]
Message-ID: <cover.1728548374.git.baolin.wang@linux.alibaba.com> (raw)

Hi,

This RFC patch series attempts to support large folios for tmpfs. 

Considering that tmpfs already has the 'huge=' option to control the THP
allocation, it is necessary to maintain compatibility with the 'huge='
option, as well as considering the 'deny' and 'force' option controlled
by '/sys/kernel/mm/transparent_hugepage/shmem_enabled'.

Add a new huge option 'write_size' to support large folio allocation based
on the write size for tmpfs write and fallocate paths. So the huge pages
allocation strategy for tmpfs is that, if the 'huge=' option
(huge=always/within_size/advise) is enabled or the 'shmem_enabled' option
is 'force', it need just allow PMD sized THP to keep backward compatibility
for tmpfs. While 'huge=' option is disabled (huge=never) or the 'shmem_enabled'
option is 'deny', it will still disable any large folio allocations. Only
when the 'huge=' option is 'write_size', it will allow allocating large
folios based on the write size.

And I think the 'huge=write_size' option should be the default behavior
for tmpfs in future.

Any comments and suggestions are appreciated. Thanks.

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 (4):
  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 to the write and fallocate paths
    for tmpfs
  docs: tmpfs: add documention for 'write_size' huge option

 Documentation/filesystems/tmpfs.rst |   7 +-
 include/linux/pagemap.h             |  16 ++++-
 mm/shmem.c                          | 105 ++++++++++++++++++++--------
 3 files changed, 94 insertions(+), 34 deletions(-)

-- 
2.39.3



             reply	other threads:[~2024-10-10  9:58 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-10  9:58 Baolin Wang [this message]
2024-10-10  9:58 ` [RFC PATCH v3 1/4] mm: factor out the order calculation into a new helper Baolin Wang
2024-10-10  9:58 ` [RFC PATCH v3 2/4] mm: shmem: change shmem_huge_global_enabled() to return huge order bitmap Baolin Wang
2024-10-13  3:30   ` kernel test robot
2024-10-16  9:30     ` Baolin Wang
2024-10-10  9:58 ` [RFC PATCH v3 3/4] mm: shmem: add large folio support to the write and fallocate paths for tmpfs Baolin Wang
2024-10-10  9:58 ` [RFC PATCH v3 4/4] docs: tmpfs: add documention for 'write_size' huge option Baolin Wang
2024-10-16  7:49 ` [RFC PATCH v3 0/4] Support large folios for tmpfs Kefeng Wang
2024-10-16  9:29   ` Baolin Wang
2024-10-16 13:45     ` Kefeng Wang
2024-10-17  9:52       ` Baolin Wang
2024-10-16 14:06 ` Matthew Wilcox
2024-10-17  9:34   ` Baolin Wang
2024-10-17 11:26     ` Kirill A. Shutemov
2024-10-21  6:24       ` Baolin Wang
2024-10-21  8:54         ` Kirill A. Shutemov
2024-10-21 13:34           ` Daniel Gomez
2024-10-22  3:41             ` Baolin Wang
2024-10-22 15:31               ` David Hildenbrand
2024-10-23  8:04                 ` Baolin Wang
2024-10-23  9:27                   ` David Hildenbrand
2024-10-24 10:49                     ` Daniel Gomez
2024-10-24 10:52                       ` Daniel Gomez
2024-10-25  2:56                       ` Baolin Wang
2024-10-25 20:21                       ` David Hildenbrand
2024-10-28  9:48                         ` David Hildenbrand
2024-10-31  3:43                           ` Baolin Wang
2024-10-31  8:53                             ` David Hildenbrand
2024-10-31 10:04                               ` Baolin Wang
2024-10-31 10:46                                 ` David Hildenbrand
2024-11-05 12:45                                   ` Baolin Wang
2024-11-05 14:56                                     ` David Hildenbrand
2024-11-06  3:17                                       ` Baolin Wang
2024-10-31 10:46                                 ` David Hildenbrand
2024-10-28 21:56                         ` Daniel Gomez
2024-10-29 12:20                           ` David Hildenbrand
2024-10-22  3:34           ` Baolin Wang
2024-10-22 10:06             ` Kirill A. Shutemov
2024-10-23  9:25               ` 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.1728548374.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.