public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 4/6] iomap: advance the iter directly on buffered writes
Date: Fri, 10 Jan 2025 12:51:15 -0500	[thread overview]
Message-ID: <Z4FeE4F4Hp_PznnV@bfoster> (raw)
In-Reply-To: <Z392eER1_ceFfMJe@infradead.org>

On Wed, Jan 08, 2025 at 11:10:48PM -0800, Christoph Hellwig wrote:
> On Fri, Dec 13, 2024 at 09:36:08AM -0500, Brian Foster wrote:
> > +		loff_t pos = iter->pos;
> > +		loff_t length = iomap_length(iter);
> 
> AFAICS we could just do away with these local variables as they should
> never get out of sync with the values in the iter.  If so I'd love to see
> that one.  If they can get out of sync and we actually need them, that
> would warrant a comment.
> 
> Otherwise this looks good to me, and the same applies to the next two
> patches.
> 

Hmm.. they should not get out of sync, but that wasn't necessarily the
point here. For one, this is trying to be incremental and highlight the
actual logic changes, but also I didn't want to just go and replace
every usage of pos with iter->pos when it only needs to be read at a
certain point.

This might be a little more clear after the (non-squashed) fbatch
patches which move where pos is sampled (to handle that it can change at
that point) and drop some of the pos function params, but if we still
want to clean that up at the end I'd rather do it as a standalone patch
at that point.

All that said, length is only used for the bytes check so I can probably
kill that one off here.

Brian


  reply	other threads:[~2025-01-10 17:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-13 14:36 [PATCH 0/6] iomap: incremental per-operation iter advance Brian Foster
2024-12-13 14:36 ` [PATCH 1/6] iomap: split out iomap check and reset logic from " 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 [this message]
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=Z4FeE4F4Hp_PznnV@bfoster \
    --to=bfoster@redhat.com \
    --cc=hch@infradead.org \
    --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