From: Luis Chamberlain <mcgrof@kernel.org>
To: hare@suse.de, willy@infradead.org, dave@stgolabs.net,
david@fromorbit.com, djwong@kernel.org, kbusch@kernel.org
Cc: john.g.garry@oracle.com, hch@lst.de, ritesh.list@gmail.com,
linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-mm@kvack.org, linux-block@vger.kernel.org,
gost.dev@samsung.com, p.raghav@samsung.com, da.gomez@samsung.com,
kernel@pankajraghav.com, mcgrof@kernel.org
Subject: [PATCH v2 0/8] enable bs > ps for block devices
Date: Tue, 4 Feb 2025 15:12:01 -0800 [thread overview]
Message-ID: <20250204231209.429356-1-mcgrof@kernel.org> (raw)
This v2 addresses feedback from the first RFC on enabling bs > ps for
block devices [0] after which I split the async read buffer-head work
into its own series [1]. This unifies the series now that this the
buffer-head work is greatly simplified, and generalizing a block size
check is now merged upstream on v6.14-rc1.
Changes in this series:
- Simplify block_read_full_folio() with bh_offset() and moves this
as a first patch
- Re-orders the negative shift patch to go first as otherwise
the blocks_per_folio changes don't make any sense
- Simplifies the amount of changes in the patch
"enable large folio support for large logical block sizes" as most
of the required changes are now upstream
- Drops the NVMe patch as its no longer needed
- Keeps the nrpages to 1 for readahead for folio for buffer-heads
as suggested by Matthew
- Takes the suggested approach by Matthew Wilcox on async read by
replacing the batched read with a straight forward iteration
- Tons of cosmetic updates as requested by folks
- Rebases on top of v6.14-rc1
- Tested with both fstests on ext4 and blktests using the latest
changes posted to support bs > ps for block devices just now [2]
- Updates the rationale for why we use 64k as the current limit:
test and validation
If you want this on a tree, this is available on the kdevops linux
large-block-buffer-heads-for-next branch [3].
[0] https://lkml.kernel.org/r/20241113094727.1497722-1-mcgrof@kernel.org
[1] https://lkml.kernel.org/r/20241218022626.3668119-1-mcgrof@kernel.org
[2] https://lkml.kernel.org/r/20250204225729.422949-1-mcgrof@kernel.org
[3] https://github.com/linux-kdevops/linux/tree/large-block-buffer-heads-for-next
Hannes Reinecke (3):
fs/mpage: avoid negative shift for large blocksize
fs/mpage: use blocks_per_folio instead of blocks_per_page
block/bdev: enable large folio support for large logical block sizes
Luis Chamberlain (4):
fs/buffer: simplify block_read_full_folio() with bh_offset()
fs/buffer fs/mpage: remove large folio restriction
block/bdev: lift block size restrictions to 64k
bdev: use bdev_io_min() for statx block size
Matthew Wilcox (1):
fs/buffer: remove batching from async read
block/bdev.c | 11 ++++----
fs/buffer.c | 58 +++++++++++++++++-------------------------
fs/mpage.c | 45 +++++++++++++++-----------------
include/linux/blkdev.h | 9 ++++++-
4 files changed, 58 insertions(+), 65 deletions(-)
--
2.45.2
next reply other threads:[~2025-02-04 23:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-04 23:12 Luis Chamberlain [this message]
2025-02-04 23:12 ` [PATCH v2 1/8] fs/buffer: simplify block_read_full_folio() with bh_offset() Luis Chamberlain
2025-02-05 16:18 ` Hannes Reinecke
2025-02-05 22:03 ` Matthew Wilcox
2025-02-06 7:17 ` Hannes Reinecke
2025-02-06 17:30 ` Luis Chamberlain
2025-02-07 7:06 ` Hannes Reinecke
2025-02-04 23:12 ` [PATCH v2 2/8] fs/buffer: remove batching from async read Luis Chamberlain
2025-02-05 16:21 ` Hannes Reinecke
2025-02-07 7:08 ` Hannes Reinecke
2025-02-17 21:40 ` Matthew Wilcox
2025-02-04 23:12 ` [PATCH v2 3/8] fs/mpage: avoid negative shift for large blocksize Luis Chamberlain
2025-02-17 21:48 ` Matthew Wilcox
2025-02-04 23:12 ` [PATCH v2 4/8] fs/mpage: use blocks_per_folio instead of blocks_per_page Luis Chamberlain
2025-02-17 21:58 ` Matthew Wilcox
2025-02-18 15:02 ` Hannes Reinecke
2025-02-21 18:58 ` Luis Chamberlain
2025-02-21 20:25 ` Matthew Wilcox
2025-02-21 20:38 ` Luis Chamberlain
2025-02-21 20:27 ` Matthew Wilcox
2025-02-21 20:39 ` Luis Chamberlain
2025-02-04 23:12 ` [PATCH v2 5/8] fs/buffer fs/mpage: remove large folio restriction Luis Chamberlain
2025-02-05 16:21 ` Hannes Reinecke
2025-02-17 21:59 ` Matthew Wilcox
2025-02-04 23:12 ` [PATCH v2 6/8] block/bdev: enable large folio support for large logical block sizes Luis Chamberlain
2025-02-17 21:59 ` Matthew Wilcox
2025-02-04 23:12 ` [PATCH v2 7/8] block/bdev: lift block size restrictions to 64k Luis Chamberlain
2025-02-17 22:01 ` Matthew Wilcox
2025-02-04 23:12 ` [PATCH v2 8/8] bdev: use bdev_io_min() for statx block size Luis Chamberlain
2025-02-05 16:22 ` Hannes Reinecke
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=20250204231209.429356-1-mcgrof@kernel.org \
--to=mcgrof@kernel.org \
--cc=da.gomez@samsung.com \
--cc=dave@stgolabs.net \
--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=kbusch@kernel.org \
--cc=kernel@pankajraghav.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=p.raghav@samsung.com \
--cc=ritesh.list@gmail.com \
--cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.