From: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>
To: willy@infradead.org
Cc: yang@os.amperecomputing.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, john.g.garry@oracle.com,
linux-fsdevel@vger.kernel.org, hare@suse.de,
p.raghav@samsung.com, mcgrof@kernel.org, gost.dev@samsung.com,
cl@os.amperecomputing.com, linux-xfs@vger.kernel.org,
ryan.roberts@arm.com, hch@lst.de, Zi Yan <ziy@nvidia.com>,
david@fromorbit.com, chandan.babu@oracle.com, djwong@kernel.org,
brauner@kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH v11 00/10] enable bs > ps in XFS
Date: Mon, 5 Aug 2024 13:24:59 +0000 [thread overview]
Message-ID: <20240805132459.ndyofuoyyojqctgt@quentin> (raw)
In-Reply-To: <20240726115956.643538-1-kernel@pankajraghav.com>
@willy
The following patches that relevant to you but are missing your RVB.
Do you think you can take a look when you have time?
readahead: allocate folios with mapping_min_order in readahead
mm: split a folio in minimum folio order chunks
--
Pankaj
> From: Pankaj Raghav <p.raghav@samsung.com>
>
> This is the 11th version of the series that enables block size > page size
> (Large Block Size) in XFS.
> The context and motivation can be seen in cover letter of the RFC v1 [0].
> We also recorded a talk about this effort at LPC [1], if someone would
> like more context on this effort.
>
> A lot of emphasis has been put on testing using kdevops, starting with an XFS
> baseline [3]. The testing has been split into regression and progression.
>
> Regression testing:
> In regression testing, we ran the whole test suite to check for regressions on
> existing profiles due to the page cache changes.
>
> I also ran split_huge_page_test selftest on XFS filesystem to check for
> huge page splits in min order chunks is done correctly.
>
> No regressions were found with these patches added on top.
>
> Progression testing:
> For progression testing, we tested for 8k, 16k, 32k and 64k block sizes. To
> compare it with existing support, an ARM VM with 64k base page system (without
> our patches) was used as a reference to check for actual failures due to LBS
> support in a 4k base page size system.
>
> There are some tests that assumes block size < page size that needs to be fixed.
> We have a tree with fixes for xfstests [4], most of the changes have been posted
> already, and only a few minor changes need to be posted. Already part of these
> changes has been upstreamed to fstests, and new tests have also been written and
> are out for review, namely for mmap zeroing-around corner cases, compaction
> and fsstress races on mm, and stress testing folio truncation on file mapped
> folios.
>
> No new failures were found with the LBS support.
>
> We've done some preliminary performance tests with fio on XFS on 4k block size
> against pmem and NVMe with buffered IO and Direct IO on vanilla Vs + these
> patches applied, and detected no regressions.
>
> We also wrote an eBPF tool called blkalgn [5] to see if IO sent to the device
> is aligned and at least filesystem block size in length.
>
> For those who want this in a git tree we have this up on a kdevops
> large-block-minorder-for-next-v11 tag [6].
>
> [0] https://lore.kernel.org/lkml/20230915183848.1018717-1-kernel@pankajraghav.com/
> [1] https://www.youtube.com/watch?v=ar72r5Xf7x4
> [2] https://lkml.kernel.org/r/20240501153120.4094530-1-willy@infradead.org
> [3] https://github.com/linux-kdevops/kdevops/blob/master/docs/xfs-bugs.md
> 489 non-critical issues and 55 critical issues. We've determined and reported
> that the 55 critical issues have all fall into 5 common XFS asserts or hung
> tasks and 2 memory management asserts.
> [4] https://github.com/linux-kdevops/fstests/tree/lbs-fixes
> [5] https://github.com/iovisor/bcc/pull/4813
> [6] https://github.com/linux-kdevops/linux/
> [7] https://lore.kernel.org/linux-kernel/Zl20pc-YlIWCSy6Z@casper.infradead.org/#t
>
> Changes since v10:
> - Revert back to silent clamping in mapping_set_folio_range().
> - Moved mapping_max_folio_size_supported() to patch 10.
> - Collected RVB from Darrick.
>
> Dave Chinner (1):
> xfs: use kvmalloc for xattr buffers
>
> Luis Chamberlain (1):
> mm: split a folio in minimum folio order chunks
>
> Matthew Wilcox (Oracle) (1):
> fs: Allow fine-grained control of folio sizes
>
> Pankaj Raghav (7):
> filemap: allocate mapping_min_order folios in the page cache
> readahead: allocate folios with mapping_min_order in readahead
> filemap: cap PTE range to be created to allowed zero fill in
> folio_map_range()
> iomap: fix iomap_dio_zero() for fs bs > system page size
> xfs: expose block size in stat
> xfs: make the calculation generic in xfs_sb_validate_fsb_count()
> xfs: enable block size larger than page size support
>
> fs/iomap/buffered-io.c | 4 +-
> fs/iomap/direct-io.c | 45 +++++++++++--
> fs/xfs/libxfs/xfs_attr_leaf.c | 15 ++---
> fs/xfs/libxfs/xfs_ialloc.c | 5 ++
> fs/xfs/libxfs/xfs_shared.h | 3 +
> fs/xfs/xfs_icache.c | 6 +-
> fs/xfs/xfs_iops.c | 2 +-
> fs/xfs/xfs_mount.c | 8 ++-
> fs/xfs/xfs_super.c | 28 +++++---
> include/linux/huge_mm.h | 14 ++--
> include/linux/pagemap.h | 122 ++++++++++++++++++++++++++++++----
> mm/filemap.c | 36 ++++++----
> mm/huge_memory.c | 59 ++++++++++++++--
> mm/readahead.c | 83 +++++++++++++++++------
> 14 files changed, 345 insertions(+), 85 deletions(-)
>
>
> base-commit: 2347b4c79f5e6cd3f4996e80c2d3c15f53006bf5
> --
> 2.44.1
>
prev parent reply other threads:[~2024-08-05 13:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-26 11:59 Pankaj Raghav (Samsung)
2024-07-26 11:59 ` [PATCH v11 01/10] fs: Allow fine-grained control of folio sizes Pankaj Raghav (Samsung)
2024-07-26 11:59 ` [PATCH v11 02/10] filemap: allocate mapping_min_order folios in the page cache Pankaj Raghav (Samsung)
2024-07-26 11:59 ` [PATCH v11 03/10] readahead: allocate folios with mapping_min_order in readahead Pankaj Raghav (Samsung)
2024-07-26 11:59 ` [PATCH v11 04/10] mm: split a folio in minimum folio order chunks Pankaj Raghav (Samsung)
2024-07-26 11:59 ` [PATCH v11 05/10] filemap: cap PTE range to be created to allowed zero fill in folio_map_range() Pankaj Raghav (Samsung)
2024-07-26 11:59 ` [PATCH v11 06/10] iomap: fix iomap_dio_zero() for fs bs > system page size Pankaj Raghav (Samsung)
2024-07-26 11:59 ` [PATCH v11 07/10] xfs: use kvmalloc for xattr buffers Pankaj Raghav (Samsung)
2024-07-26 11:59 ` [PATCH v11 08/10] xfs: expose block size in stat Pankaj Raghav (Samsung)
2024-07-26 11:59 ` [PATCH v11 09/10] xfs: make the calculation generic in xfs_sb_validate_fsb_count() Pankaj Raghav (Samsung)
2024-07-26 11:59 ` [PATCH v11 10/10] xfs: enable block size larger than page size support Pankaj Raghav (Samsung)
2024-07-29 2:08 ` Dave Chinner
2024-07-29 16:41 ` Darrick J. Wong
2024-08-05 12:46 ` Pankaj Raghav (Samsung)
2024-08-05 13:24 ` Pankaj Raghav (Samsung) [this message]
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=20240805132459.ndyofuoyyojqctgt@quentin \
--to=kernel@pankajraghav.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=cl@os.amperecomputing.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=gost.dev@samsung.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=john.g.garry@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=p.raghav@samsung.com \
--cc=ryan.roberts@arm.com \
--cc=willy@infradead.org \
--cc=yang@os.amperecomputing.com \
--cc=ziy@nvidia.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