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
