linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zi Yan <zi.yan@sent.com>
To: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>, linux-mm@kvack.org
Cc: "Zi Yan" <ziy@nvidia.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	"David Hildenbrand" <david@redhat.com>,
	"Yang Shi" <shy828301@gmail.com>, "Yu Zhao" <yuzhao@google.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	"Ryan Roberts" <ryan.roberts@arm.com>,
	"Michal Koutný" <mkoutny@suse.com>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"Zach O'Keefe" <zokeefe@google.com>,
	"Hugh Dickins" <hughd@google.com>,
	"Luis Chamberlain" <mcgrof@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: [PATCH v5 0/8] Split a folio to any lower order folios
Date: Mon, 26 Feb 2024 15:55:26 -0500	[thread overview]
Message-ID: <20240226205534.1603748-1-zi.yan@sent.com> (raw)

From: Zi Yan <ziy@nvidia.com>

Hi all,

File folio supports any order and multi-size THP is upstreamed[1], so both
file and anonymous folios can be >0 order. Currently, split_huge_page()
only splits a huge page to order-0 pages, but splitting to orders higher than
0 might better utilize large folios, if done properly. In addition,
Large Block Sizes in XFS support would benefit from it during truncate[2].
This patchset adds support for splitting a large folio to any lower order
folios. The patchset is on top of mm-everything-2024-02-24-02-40.

In addition to this implementation of split_huge_page_to_list_to_order(),
a possible optimization could be splitting a large folio to arbitrary
smaller folios instead of a single order. As both Hugh and Ryan pointed
out [3,5] that split to a single order might not be optimal, an order-9 folio
might be better split into 1 order-8, 1 order-7, ..., 1 order-1, and 2 order-0
folios, depending on subsequent folio operations. Leave this as future work.


Changelog
===

Since v4[4]
1. Picked up Matthew's order-1 folio support in the page cache patch, so
   that XFS Large Block Sizes patchset can avoid additional code churn in
   split_huge_page_to_list_to_order().
2. Dropped truncate change patch and corresponding testing code.
3. Removed thp_nr_pages() use in __split_huge_page()
   (per David Hildenbrand).
4. Fixed __split_page_owner() (per David Hildenbrand).
5. Changed unmap_folio() to only add TTU_SPLIT_HUGE_PMD if the folios is
   pmd mappable (per Ryan Roberts).
6. Moved swapcached folio split warning upfront and return -EINVAL
   (per Ryan Roberts).

Since v3
---
1. Excluded shmem folios and pagecache folios without FS support from
   splitting to any order (per Hugh Dickins).
2. Allowed splitting anonymous large folio to any lower order since
   multi-size THP is upstreamed.
3. Adapted selftests code to new framework.

Since v2
---
1. Fixed an issue in __split_page_owner() introduced during my rebase

Since v1
---
1. Changed split_page_memcg() and split_page_owner() parameter to use order
2. Used folio_test_pmd_mappable() in place of the equivalent code

Details
===

* Patch 1 changes unmap_folio() to only add TTU_SPLIT_HUGE_PMD if the
  folio is pmd mappable.
* Patch 2 adds support for order-1 page cache folio.
* Patch 3 changes split_page_memcg() to use order instead of nr_pages.
* Patch 4 changes split_page_owner() to use order instead of nr_pages.
* Patch 5 and 6 add new_order parameter split_page_memcg() and
  split_page_owner() and prepare for upcoming changes.
* Patch 7 adds split_huge_page_to_list_to_order() to split a huge page
  to any lower order. The original split_huge_page_to_list() calls
  split_huge_page_to_list_to_order() with new_order = 0.
* Patch 8 adds a test API to debugfs and test cases in
  split_huge_page_test selftests.

Comments and/or suggestions are welcome.

[1] https://lore.kernel.org/all/20231207161211.2374093-1-ryan.roberts@arm.com/
[2] https://lore.kernel.org/linux-mm/20240226094936.2677493-1-kernel@pankajraghav.com/
[3] https://lore.kernel.org/linux-mm/9dd96da-efa2-5123-20d4-4992136ef3ad@google.com/
[4] https://lore.kernel.org/linux-mm/cbb1d6a0-66dd-47d0-8733-f836fe050374@arm.com/
[5] https://lore.kernel.org/linux-mm/20240213215520.1048625-1-zi.yan@sent.com/


Matthew Wilcox (Oracle) (1):
  mm: Support order-1 folios in the page cache

Zi Yan (7):
  mm/huge_memory: only split PMD mapping when necessary in unmap_folio()
  mm/memcg: use order instead of nr in split_page_memcg()
  mm/page_owner: use order instead of nr in split_page_owner()
  mm: memcg: make memcg huge page split support any order split.
  mm: page_owner: add support for splitting to any order in split
    page_owner.
  mm: thp: split huge page to any lower order pages
  mm: huge_memory: enable debugfs to split huge pages to any order.

 include/linux/huge_mm.h                       |  21 ++-
 include/linux/memcontrol.h                    |   4 +-
 include/linux/page_owner.h                    |  14 +-
 mm/filemap.c                                  |   2 -
 mm/huge_memory.c                              | 173 +++++++++++++-----
 mm/internal.h                                 |   3 +-
 mm/memcontrol.c                               |  10 +-
 mm/page_alloc.c                               |   8 +-
 mm/page_owner.c                               |   6 +-
 mm/readahead.c                                |   3 -
 .../selftests/mm/split_huge_page_test.c       | 115 +++++++++++-
 11 files changed, 276 insertions(+), 83 deletions(-)

-- 
2.43.0



             reply	other threads:[~2024-02-26 20:56 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-26 20:55 Zi Yan [this message]
2024-02-26 20:55 ` [PATCH v5 1/8] mm/huge_memory: only split PMD mapping when necessary in unmap_folio() Zi Yan
2024-02-28 10:30   ` David Hildenbrand
2024-02-26 20:55 ` [PATCH v5 2/8] mm: Support order-1 folios in the page cache Zi Yan
2024-02-26 20:55 ` [PATCH v5 3/8] mm/memcg: use order instead of nr in split_page_memcg() Zi Yan
2024-02-26 20:55 ` [PATCH v5 4/8] mm/page_owner: use order instead of nr in split_page_owner() Zi Yan
2024-02-26 20:55 ` [PATCH v5 5/8] mm: memcg: make memcg huge page split support any order split Zi Yan
2024-02-26 20:55 ` [PATCH v5 6/8] mm: page_owner: add support for splitting to any order in split page_owner Zi Yan
2024-02-28 10:31   ` David Hildenbrand
2024-02-26 20:55 ` [PATCH v5 7/8] mm: thp: split huge page to any lower order pages Zi Yan
2024-02-28  8:23   ` Ryan Roberts
2024-02-28 15:42     ` Zi Yan
2024-02-28 15:44       ` Ryan Roberts
2024-02-28 15:52   ` Zi Yan
2024-03-07 14:58   ` Zi Yan
2024-02-26 20:55 ` [PATCH v5 8/8] mm: huge_memory: enable debugfs to split huge pages to any order Zi Yan
2024-03-01  9:51   ` Aishwarya TCV
2024-03-01 10:33     ` Ryan Roberts
2024-03-01 12:11       ` Mark Brown
2024-03-01 12:56         ` Zi Yan
2024-03-01 14:14           ` Mark Brown
2024-03-01 12:52       ` Zi Yan
2024-03-01 13:09         ` Ryan Roberts
2024-03-01 13:53           ` Zi Yan
2024-03-01 14:18             ` Ryan Roberts
2024-03-01 14:27               ` Mark Brown
2024-03-01 15:21                 ` Zi Yan
2024-03-01 19:41                 ` Zi Yan
2024-03-01 14:24           ` Mark Brown
2024-03-01 14:00     ` Zi Yan
2024-03-01 14:23       ` Ryan Roberts
2024-03-01 14:33         ` Zi Yan
2024-03-01 19:37     ` Zi Yan
2024-03-01 20:02       ` Zi Yan
2024-03-01 21:10         ` Zi Yan
2024-03-04  9:50           ` Aishwarya TCV
2024-03-04 14:58             ` Zi Yan
2024-03-04 15:44               ` Aishwarya TCV
2024-03-04 15:57                 ` Zi Yan
2024-03-04 18:25                   ` Aishwarya TCV
2024-03-04 18:26                     ` Zi Yan
2024-03-04 18:31                   ` Zi Yan
2024-03-07 15:06   ` Zi Yan

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=20240226205534.1603748-1-zi.yan@sent.com \
    --to=zi.yan@sent.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=kernel@pankajraghav.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mcgrof@kernel.org \
    --cc=mkoutny@suse.com \
    --cc=roman.gushchin@linux.dev \
    --cc=ryan.roberts@arm.com \
    --cc=shy828301@gmail.com \
    --cc=willy@infradead.org \
    --cc=yuzhao@google.com \
    --cc=ziy@nvidia.com \
    --cc=zokeefe@google.com \
    /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).