Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: linux-fsdevel@vger.kernel.org
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH v3 00/25] Large pages in the page cache
Date: Wed, 29 Apr 2020 06:36:32 -0700	[thread overview]
Message-ID: <20200429133657.22632-1-willy@infradead.org> (raw)

From: "Matthew Wilcox (Oracle)" <willy@infradead.org>

This patch set does not pass xfstests.  Test at your own risk.  It is
based on the readahead rewrite which is in Andrew's tree.  The large
pages somehow manage to fall off the LRU, so the test VM quickly runs
out of memory and freezes.  To reproduce:

# mkfs.xfs /dev/sdb && mount /dev/sdb /mnt && dd if=/dev/zero bs=1M count=2048 of=/mnt/bigfile && sync && sleep 2 && sync && echo 1 >/proc/sys/vm/drop_caches 
# /host/home/willy/kernel/xarray-2/tools/vm/page-types | grep thp
0x0000000000401800	       511        1  ___________Ma_________t____________________	mmap,anonymous,thp
0x0000000000405868	         1        0  ___U_lA____Ma_b_______t____________________	uptodate,lru,active,mmap,anonymous,swapbacked,thp
# dd if=/mnt/bigfile of=/dev/null bs=2M count=5
# /host/home/willy/kernel/xarray-2/tools/vm/page-types | grep thp
0x0000000000400000	      2516        9  ______________________t____________________	thp
0x0000000000400028	         1        0  ___U_l________________t____________________	uptodate,lru,thp
0x000000000040006c	       106        0  __RU_lA_______________t____________________	referenced,uptodate,lru,active,thp
0x0000000000400228	         1        0  ___U_l___I____________t____________________	uptodate,lru,reclaim,thp
0x0000000000401800	       511        1  ___________Ma_________t____________________	mmap,anonymous,thp
0x0000000000405868	         1        0  ___U_lA____Ma_b_______t____________________	uptodate,lru,active,mmap,anonymous,swapbacked,thp


The principal idea here is that a large part of the overhead in dealing
with individual pages is that there's just so darned many of them.  We
would be better off dealing with fewer, larger pages, even if they don't
get to be the size necessary for the CPU to use a larger TLB entry.

Matthew Wilcox (Oracle) (24):
  mm: Allow hpages to be arbitrary order
  mm: Introduce thp_size
  mm: Introduce thp_order
  mm: Introduce offset_in_thp
  fs: Add a filesystem flag for large pages
  fs: Introduce i_blocks_per_page
  fs: Make page_mkwrite_check_truncate thp-aware
  fs: Support THPs in zero_user_segments
  bio: Add bio_for_each_thp_segment_all
  iomap: Support arbitrarily many blocks per page
  iomap: Support large pages in iomap_adjust_read_range
  iomap: Support large pages in read paths
  iomap: Support large pages in write paths
  iomap: Inline data shouldn't see large pages
  xfs: Support large pages
  mm: Make prep_transhuge_page return its argument
  mm: Add __page_cache_alloc_order
  mm: Allow large pages to be added to the page cache
  mm: Allow large pages to be removed from the page cache
  mm: Remove page fault assumption of compound page size
  mm: Add DEFINE_READAHEAD
  mm: Make page_cache_readahead_unbounded take a readahead_control
  mm: Make __do_page_cache_readahead take a readahead_control
  mm: Add large page readahead

William Kucharski (1):
  mm: Align THP mappings for non-DAX

 drivers/nvdimm/btt.c    |   4 +-
 drivers/nvdimm/pmem.c   |   6 +-
 fs/ext4/verity.c        |   4 +-
 fs/f2fs/verity.c        |   4 +-
 fs/iomap/buffered-io.c  | 110 ++++++++++++++++--------------
 fs/jfs/jfs_metapage.c   |   2 +-
 fs/xfs/xfs_aops.c       |   4 +-
 fs/xfs/xfs_super.c      |   2 +-
 include/linux/bio.h     |  13 ++++
 include/linux/bvec.h    |  23 +++++++
 include/linux/fs.h      |   1 +
 include/linux/highmem.h |  15 +++--
 include/linux/huge_mm.h |  25 +++++--
 include/linux/mm.h      |  97 ++++++++++++++-------------
 include/linux/pagemap.h |  62 ++++++++++++++---
 mm/filemap.c            |  60 ++++++++++++-----
 mm/highmem.c            |  62 ++++++++++++++++-
 mm/huge_memory.c        |  49 ++++++--------
 mm/internal.h           |  13 ++--
 mm/memory.c             |   7 +-
 mm/page_io.c            |   2 +-
 mm/page_vma_mapped.c    |   4 +-
 mm/readahead.c          | 145 ++++++++++++++++++++++++++++++----------
 23 files changed, 485 insertions(+), 229 deletions(-)

-- 
2.26.2


             reply	other threads:[~2020-04-29 13:37 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29 13:36 Matthew Wilcox [this message]
2020-04-29 13:36 ` [PATCH v3 01/25] mm: Allow hpages to be arbitrary order Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 02/25] mm: Introduce thp_size Matthew Wilcox
2020-05-06 17:59   ` Yang Shi
2020-04-29 13:36 ` [PATCH v3 03/25] mm: Introduce thp_order Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 04/25] mm: Introduce offset_in_thp Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 05/25] fs: Add a filesystem flag for large pages Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 06/25] fs: Introduce i_blocks_per_page Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 07/25] fs: Make page_mkwrite_check_truncate thp-aware Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 08/25] fs: Support THPs in zero_user_segments Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 09/25] bio: Add bio_for_each_thp_segment_all Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 10/25] iomap: Support arbitrarily many blocks per page Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 11/25] iomap: Support large pages in iomap_adjust_read_range Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 12/25] iomap: Support large pages in read paths Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 13/25] iomap: Support large pages in write paths Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 14/25] iomap: Inline data shouldn't see large pages Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 15/25] xfs: Support " Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 16/25] mm: Make prep_transhuge_page return its argument Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 17/25] mm: Add __page_cache_alloc_order Matthew Wilcox
2020-05-06 18:03   ` Yang Shi
2020-06-07  3:08     ` Matthew Wilcox
2020-06-09 17:38       ` Yang Shi
2020-04-29 13:36 ` [PATCH v3 18/25] mm: Allow large pages to be added to the page cache Matthew Wilcox
2020-05-04  3:10   ` Matthew Wilcox
2020-05-06 18:32     ` Yang Shi
2020-06-07  3:04     ` Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 19/25] mm: Allow large pages to be removed from " Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 20/25] mm: Remove page fault assumption of compound page size Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 21/25] mm: Add DEFINE_READAHEAD Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 22/25] mm: Make page_cache_readahead_unbounded take a readahead_control Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 23/25] mm: Make __do_page_cache_readahead " Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 24/25] mm: Add large page readahead Matthew Wilcox
2020-04-29 13:36 ` [PATCH v3 25/25] mm: Align THP mappings for non-DAX Matthew Wilcox
2020-04-29 15:40 ` [PATCH v3 00/25] Large pages in the page cache Kirill A. Shutemov
2020-04-29 15:45   ` Kirill A. Shutemov
2020-04-30 11:34 ` Matthew Wilcox

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=20200429133657.22632-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 \
    --subject='Re: [PATCH v3 00/25] Large pages in the page cache' \
    /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

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).