From: Brian Foster <bfoster@redhat.com>
To: linux-fsdevel@vger.kernel.org
Cc: linux-xfs@vger.kernel.org
Subject: [PATCH v2 0/7] iomap: incremental per-operation iter advance
Date: Wed, 22 Jan 2025 08:34:27 -0500 [thread overview]
Message-ID: <20250122133434.535192-1-bfoster@redhat.com> (raw)
Hi all,
Here's v2 of the iomap incremental iter advance series. This is mostly
the same idea as v1 with some of the cleanups noted below. The most
significant change is probably a bit more rework of the logic between
iomap_iter_advance() and iomap_iter() to make the former a bit more
generic. _advance() now returns the remaining length for the current
mapping for easier use in some of the iter handlers.
The other item of note for v1 was some discussion with Christoph over
changing over more of the operations to advance directly and avoid the
need to handle both types of advances in the iomap_iter() code. I don't
plan to address that in this series, but I've read through some of the
related code and think that perhaps this isn't as invasive as I
originally anticipated. Reason being that even some of the more complex
operations (i.e. direct I/O, buffered read) don't necessarily require
plumbing advances all the way down through the sub-helpers and whatnot
to eliminate the dependency from iomap_iter(). IOW, I think toplevel
direct I/O could just change to something like so:
iter.processed = iomap_dio_iter(...);
if (iter.processed > 0) {
iomap_iter_advance(..., processed);
iter.processed = 0; /* success */
}
... to translate the op-specific code into the updated iteration
semantics. Given that, I'll probably make a quick stab at that once this
series is settled and we'll see how that pans out.
Thoughts, reviews, flames appreciated.
Brian
v2:
- More refactoring of iomap_iter[_advance]() logic. Lifted out iter
continuation and stale logic and improved comments.
- Renamed some poorly named helpers and variables.
- Return remaining length for current iter from _iter_advance() and use
appropriately.
v1: https://lore.kernel.org/linux-fsdevel/20241213143610.1002526-1-bfoster@redhat.com/
- Reworked and fixed a bunch of functional issues.
RFC: https://lore.kernel.org/linux-fsdevel/20241125140623.20633-1-bfoster@redhat.com/
Brian Foster (7):
iomap: split out iomap check and reset logic from iter advance
iomap: factor out iomap length helper
iomap: refactor iter and advance continuation logic
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 | 50 ++++++++-------------
fs/iomap/iter.c | 99 ++++++++++++++++++++++++++----------------
include/linux/iomap.h | 20 ++++++---
3 files changed, 94 insertions(+), 75 deletions(-)
--
2.47.1
next reply other threads:[~2025-01-22 13:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-22 13:34 Brian Foster [this message]
2025-01-22 13:34 ` [PATCH v2 1/7] iomap: split out iomap check and reset logic from iter advance Brian Foster
2025-01-22 13:34 ` [PATCH v2 2/7] iomap: factor out iomap length helper Brian Foster
2025-01-28 5:26 ` Christoph Hellwig
2025-01-28 13:53 ` Brian Foster
2025-01-22 13:34 ` [PATCH v2 3/7] iomap: refactor iter and advance continuation logic Brian Foster
2025-01-28 5:34 ` Christoph Hellwig
2025-01-28 13:55 ` Brian Foster
2025-01-29 5:50 ` Christoph Hellwig
2025-01-22 13:34 ` [PATCH v2 4/7] iomap: support incremental iomap_iter advances Brian Foster
2025-01-28 5:35 ` Christoph Hellwig
2025-01-22 13:34 ` [PATCH v2 5/7] iomap: advance the iter directly on buffered writes Brian Foster
2025-01-28 5:36 ` Christoph Hellwig
2025-01-22 13:34 ` [PATCH v2 6/7] iomap: advance the iter directly on unshare range Brian Foster
2025-01-28 5:39 ` Christoph Hellwig
2025-01-28 13:57 ` Brian Foster
2025-01-29 5:58 ` Christoph Hellwig
2025-01-28 17:59 ` Brian Foster
2025-01-29 5:56 ` Christoph Hellwig
2025-01-29 16:40 ` Brian Foster
2025-01-22 13:34 ` [PATCH v2 7/7] iomap: advance the iter directly on zero range Brian Foster
2025-01-28 5:40 ` 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=20250122133434.535192-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