From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Subject: [PATCH 00/12] Enabling large folios for 5.17
Date: Sun, 16 Jan 2022 12:18:10 +0000 [thread overview]
Message-ID: <20220116121822.1727633-1-willy@infradead.org> (raw)
Is Linux just too stable for you? Tired of not having your data eaten
by a grue? Then it's time to experiment with enabling large folios!
You will need:
- A recent Linus tree (I used a33f5c380c4b)
- To enable CONFIG_TRANSPARENT_HUGEPAGE
- An XFS filesystem
- Your favourite workload
These patches create large folios in the readahead and fault paths.
They do not create large folios in the write path; that is future
work. For most workloads, this is quite sufficient. You can
monitor the sizes of folios being added to the page cache with the
mm_filemap_add_to_page_cache tracepoint.
As mentioned in the 'Add large folio readahead' commit message, the
heuristic for deciding when to enlarge the size of the folio being
created is stupid. I'm sure somebody out there can do better.
This patchset is not (as far as I'm concerned) a candidate for merging
into 5.17. It hasn't been in linux-next, and while it does not introduce
any regressions in my testing, I'd be uncomfortable seeing it merged
before 5.18.
Matthew Wilcox (Oracle) (11):
mm: Add folio_put_refs()
filemap: Use folio_put_refs() in filemap_free_folio()
filemap: Allow large folios to be added to the page cache
mm/vmscan: Free non-shmem folios without splitting them
mm: Fix READ_ONLY_THP warning
mm/vmscan: Optimise shrink_page_list for non-PMD-sized folios
mm: Make large folios depend on THP
mm/readahead: Add large folio readahead
mm/readahead: Switch to page_cache_ra_order
mm/filemap: Support VM_HUGEPAGE for file mappings
selftests/vm/transhuge-stress: Support file-backed PMD folios
William Kucharski (1):
mm/readahead: Align file mappings for non-DAX
include/linux/mm.h | 20 ++++
include/linux/pagemap.h | 11 +-
mm/filemap.c | 69 +++++++----
mm/huge_memory.c | 5 +-
mm/internal.h | 4 +-
mm/readahead.c | 108 ++++++++++++++++--
mm/vmscan.c | 7 +-
tools/testing/selftests/vm/transhuge-stress.c | 35 ++++--
8 files changed, 204 insertions(+), 55 deletions(-)
--
2.34.1
next reply other threads:[~2022-01-16 12:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-16 12:18 Matthew Wilcox (Oracle) [this message]
2022-01-16 12:18 ` [PATCH 01/12] mm: Add folio_put_refs() Matthew Wilcox (Oracle)
2022-01-16 12:18 ` [PATCH 02/12] filemap: Use folio_put_refs() in filemap_free_folio() Matthew Wilcox (Oracle)
2022-01-17 15:56 ` Kirill A. Shutemov
2022-01-17 16:11 ` Matthew Wilcox
2022-01-16 12:18 ` [PATCH 03/12] filemap: Allow large folios to be added to the page cache Matthew Wilcox (Oracle)
2022-01-16 12:18 ` [PATCH 04/12] mm/vmscan: Free non-shmem folios without splitting them Matthew Wilcox (Oracle)
2022-01-17 16:06 ` Kirill A. Shutemov
2022-01-17 16:10 ` Matthew Wilcox
2022-01-17 21:00 ` Kirill A. Shutemov
2022-01-16 12:18 ` [PATCH 05/12] mm: Fix READ_ONLY_THP warning Matthew Wilcox (Oracle)
2022-01-16 12:18 ` [PATCH 06/12] mm/vmscan: Optimise shrink_page_list for non-PMD-sized folios Matthew Wilcox (Oracle)
2022-01-16 12:18 ` [PATCH 07/12] mm: Make large folios depend on THP Matthew Wilcox (Oracle)
2022-01-16 12:18 ` [PATCH 08/12] mm/readahead: Add large folio readahead Matthew Wilcox (Oracle)
2022-01-16 12:18 ` [PATCH 09/12] mm/readahead: Align file mappings for non-DAX Matthew Wilcox (Oracle)
2022-01-17 3:17 ` Rongwei Wang
2022-01-17 4:40 ` Matthew Wilcox
2022-01-16 12:18 ` [PATCH 10/12] mm/readahead: Switch to page_cache_ra_order Matthew Wilcox (Oracle)
2022-01-16 12:18 ` [PATCH 11/12] mm/filemap: Support VM_HUGEPAGE for file mappings Matthew Wilcox (Oracle)
2022-01-16 12:18 ` [PATCH 12/12] selftests/vm/transhuge-stress: Support file-backed PMD folios Matthew Wilcox (Oracle)
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=20220116121822.1727633-1-willy@infradead.org \
--to=willy@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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).