From: Brian Foster <bfoster@redhat.com>
To: linux-fsdevel@vger.kernel.org
Cc: linux-xfs@vger.kernel.org
Subject: [PATCH 0/6] iomap: incremental per-operation iter advance
Date: Fri, 13 Dec 2024 09:36:04 -0500 [thread overview]
Message-ID: <20241213143610.1002526-1-bfoster@redhat.com> (raw)
Hi all,
This is a first pass at supporting more incremental, per-operation
iomap_iter advancement. The motivation for this is folio_batch support
for zero range [1], where the fs provides a batch of folios to process
in certain situations. Since the batch may not be logically contiguous,
processing loops require a bit more flexibility than the typical offset
based iteration.
The current iteration model basically has the operation _iter() handler
lift the pos/length wrt to the current iomap out of the iomap_iter,
process it locally, then return the result to be stored in
iter.processed. The latter is overloaded with error status, so the
handler must decide whether to return error or a partial completion
(i.e. consider a short write). iomap_iter() then uses the result to
advance the iter and look up the next iomap.
The updated model proposed in this series is to allow an operation to
advance the iter itself as subranges are processed and then return
success or failure in iter.processed. Note that at least initially, this
is implemented as an optional mode to minimize churn. This series
converts operations that use iomap_write_begin(): buffered write,
unshare, and zero range.
The main advantage of this is that the future folio_batch work can be
plumbed down into the folio get path more naturally, and the
associated codepath can advance the iter itself when appropriate rather
than require each operation to manage the gaps in the range being
processed. Some secondary advantages are a little less boilerplate code
for walking ranges and more clear semantics for partial completions in
the event of errors, etc.
I'll post an RFC of the folio_batch work shortly after this to give an
example of how this is intended to be used. Otherwise, the changes here
actually aren't all that substantial. Patches 1-2 are prep work, patch 3
enables incremental advances, and patches 4-6 switch over a few
operations. Thoughts, reviews, flames appreciated.
Brian
v1:
- Reworked and fixed a bunch of functional issues.
RFC: https://lore.kernel.org/linux-fsdevel/20241125140623.20633-1-bfoster@redhat.com/
[1] https://lore.kernel.org/linux-fsdevel/20241119154656.774395-1-bfoster@redhat.com/
Brian Foster (6):
iomap: split out iomap check and reset logic from iter advance
iomap: factor out iomap length helper
iomap: support incremental iomap_iter advances
iomap: advance the iter directly on buffered writes
iomap: advance the iter directly on unshare range
iomap: advance the iter directly on zero range
fs/iomap/buffered-io.c | 46 ++++++++++-----------------
fs/iomap/iter.c | 72 ++++++++++++++++++++++++++----------------
include/linux/iomap.h | 14 ++++++--
3 files changed, 73 insertions(+), 59 deletions(-)
--
2.47.0
next reply other threads:[~2024-12-13 14:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-13 14:36 Brian Foster [this message]
2024-12-13 14:36 ` [PATCH 1/6] iomap: split out iomap check and reset logic from iter advance Brian Foster
2025-01-09 7:00 ` Christoph Hellwig
2024-12-13 14:36 ` [PATCH 2/6] iomap: factor out iomap length helper Brian Foster
2025-01-09 7:02 ` Christoph Hellwig
2025-01-10 17:49 ` Brian Foster
2025-01-13 4:46 ` Christoph Hellwig
2024-12-13 14:36 ` [PATCH 3/6] iomap: support incremental iomap_iter advances Brian Foster
2025-01-09 7:07 ` Christoph Hellwig
2025-01-10 17:50 ` Brian Foster
2025-01-13 4:48 ` Christoph Hellwig
2025-01-13 14:25 ` Brian Foster
2024-12-13 14:36 ` [PATCH 4/6] iomap: advance the iter directly on buffered writes Brian Foster
2025-01-09 7:10 ` Christoph Hellwig
2025-01-10 17:51 ` Brian Foster
2025-01-15 5:46 ` Christoph Hellwig
2024-12-13 14:36 ` [PATCH 5/6] iomap: advance the iter directly on unshare range Brian Foster
2024-12-13 14:36 ` [PATCH 6/6] iomap: advance the iter directly on zero range Brian Foster
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=20241213143610.1002526-1-bfoster@redhat.com \
--to=bfoster@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.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