From: Luis Chamberlain <mcgrof@kernel.org>
To: willy@infradead.org, hch@lst.de, hare@suse.de,
david@fromorbit.com, djwong@kernel.org
Cc: john.g.garry@oracle.com, ritesh.list@gmail.com,
kbusch@kernel.org, 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: [RFC 0/8] enable bs > ps for block devices
Date: Wed, 13 Nov 2024 01:47:19 -0800 [thread overview]
Message-ID: <20241113094727.1497722-1-mcgrof@kernel.org> (raw)
The last time this was addressed was at LFSMM this year in May [0] and
before LBS was on its way upstream. LBS is now on v6.12 and so the delta
required is much smaller now.
Before the turkey massacre slows part of the world down, here's a refresh.
Although Hannes' patches were in PATCH form, testing showed quickly that
it wasn't quite ready yet. I've only done cursory testing so far but have
also incorporated all of the fixes and feedback we could accumulate over
time. And so I'm sticking to RFC to reflect that this still needs thorough
testing. It at least does not crash for me yet and its a major rebase
onto v6.12-rc7.
The biggest changes now are these last patches:
- block/bdev: lift block size restrictions and use common definition
- nvme: remove superfluous block size check
- bdev: use bdev_io_min() for statx block size
The buffer-head pathces I think should be ready.
If the consolidation of the max block size is good, perhaps we just also use it
for the iomap max zero page too. Note that in theory we should be able to get
up to a block size of 1 << (PAGE_SHIFT + MAX_PAGECACHE_ORDER), in practice
testing that shows we need much more love [1] although prospects indeed show
we should be able to get up to 2 MiB on x86_64. And so I think we should first
reduce scope up to 64k for now, test all this, and then embark on the next
64k --> 2 MiB journey next.
Thoughts?
If you want this in a tree you can get this from the kdevops branch
large-block-buffer-heads-for-next [2]
[0] https://lore.kernel.org/all/20240514173900.62207-1-hare@kernel.org/
[1] https://github.com/linux-kdevops/linux/commit/266f2c700be55bdb5626d521230597673c83c91d#diff-79b436371fdb3ddf0e7ad9bd4c9afe05160f7953438e650a77519b882904c56bL272
[2] https://github.com/linux-kdevops/linux/tree/large-block-buffer-heads-for-next
Hannes Reinecke (4):
fs/mpage: use blocks_per_folio instead of blocks_per_page
fs/mpage: avoid negative shift for large blocksize
fs/buffer: restart block_read_full_folio() to avoid array overflow
block/bdev: enable large folio support for large logical block sizes
Luis Chamberlain (4):
fs/buffer fs/mpage: remove large folio restriction
block/bdev: lift block size restrictions and use common definition
nvme: remove superfluous block size check
bdev: use bdev_io_min() for statx block size
block/bdev.c | 9 +++++---
drivers/nvme/host/core.c | 10 ---------
fs/buffer.c | 21 ++++++++++++++----
fs/mpage.c | 47 +++++++++++++++++++---------------------
fs/stat.c | 2 +-
include/linux/blkdev.h | 6 ++++-
6 files changed, 51 insertions(+), 44 deletions(-)
--
2.43.0
next reply other threads:[~2024-12-05 15:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-13 9:47 Luis Chamberlain [this message]
2024-11-13 9:47 ` [RFC 1/8] fs/mpage: use blocks_per_folio instead of blocks_per_page Luis Chamberlain
2024-11-13 9:47 ` [RFC 2/8] fs/mpage: avoid negative shift for large blocksize Luis Chamberlain
2024-11-13 14:06 ` Matthew Wilcox
2024-11-14 13:47 ` Hannes Reinecke
2024-11-13 9:47 ` [RFC 3/8] fs/buffer: restart block_read_full_folio() to avoid array overflow Luis Chamberlain
2024-11-13 18:50 ` Matthew Wilcox
2024-11-13 9:47 ` [RFC 4/8] fs/buffer fs/mpage: remove large folio restriction Luis Chamberlain
2024-11-13 9:55 ` Hannes Reinecke
2024-11-13 9:47 ` [RFC 5/8] block/bdev: enable large folio support for large logical block sizes Luis Chamberlain
2024-11-13 9:47 ` [RFC 6/8] block/bdev: lift block size restrictions and use common definition Luis Chamberlain
2024-11-13 9:57 ` Hannes Reinecke
2024-11-13 14:14 ` Matthew Wilcox
2024-11-18 9:18 ` John Garry
2024-11-13 9:47 ` [RFC 7/8] nvme: remove superfluous block size check Luis Chamberlain
2024-11-13 9:57 ` Hannes Reinecke
2024-11-13 9:47 ` [RFC 8/8] bdev: use bdev_io_min() for statx block size Luis Chamberlain
2024-11-13 9:59 ` Hannes Reinecke
2024-11-18 7:08 ` Christoph Hellwig
2024-11-18 21:16 ` Luis Chamberlain
2024-11-19 6:08 ` Christoph Hellwig
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=20241113094727.1497722-1-mcgrof@kernel.org \
--to=mcgrof@kernel.org \
--cc=da.gomez@samsung.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox