From: Matthew Wilcox <willy@infradead.org>
To: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Dave Chinner <david@fromorbit.com>,
Brian Foster <bfoster@redhat.com>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
Disha Goel <disgoel@linux.ibm.com>,
Aravinda Herle <araherle@in.ibm.com>
Subject: Re: [RFCv4 3/3] iomap: Support subpage size dirty tracking to improve write performance
Date: Thu, 4 May 2023 16:02:48 +0100 [thread overview]
Message-ID: <ZFPJGDqfcUtI4ptO@casper.infradead.org> (raw)
In-Reply-To: <377c30e7b5f2783dd5be12c59ea703d7c72ba004.1683208091.git.ritesh.list@gmail.com>
On Thu, May 04, 2023 at 08:21:09PM +0530, Ritesh Harjani (IBM) wrote:
> @@ -90,12 +116,21 @@ iomap_page_create(struct inode *inode, struct folio *folio, unsigned int flags)
> else
> gfp = GFP_NOFS | __GFP_NOFAIL;
>
> - iop = kzalloc(struct_size(iop, state, BITS_TO_LONGS(nr_blocks)),
> + /*
> + * iop->state tracks two sets of state flags when the
> + * filesystem block size is smaller than the folio size.
> + * The first state tracks per-filesystem block uptodate
> + * and the second tracks per-filesystem block dirty
> + * state.
> + */
"per-filesystem"? I think you mean "per-block (uptodate|block) state".
Using "per-block" naming throughout this patchset might help readability.
It's currently an awkward mix of "subpage", "sub-page" and "sub-folio".
It also feels like you're adding a comment to every non-mechanical change
you make, which isn't necessarily helpful. Changelog, sure, but
sometimes your comments simply re-state what your change is doing.
> -static void iomap_iop_set_range_uptodate(struct folio *folio,
> - struct iomap_page *iop, size_t off, size_t len)
> +static void iomap_iop_set_range(struct folio *folio, struct iomap_page *iop,
> + size_t off, size_t len, enum iop_state state)
> {
> struct inode *inode = folio->mapping->host;
> - unsigned first = off >> inode->i_blkbits;
> - unsigned last = (off + len - 1) >> inode->i_blkbits;
> + unsigned int blks_per_folio = i_blocks_per_folio(inode, folio);
> + unsigned int first_blk = (off >> inode->i_blkbits);
> + unsigned int last_blk = ((off + len - 1) >> inode->i_blkbits);
> + unsigned int nr_blks = last_blk - first_blk + 1;
> unsigned long flags;
> - unsigned int nr_blocks = i_blocks_per_folio(inode, folio);
>
> - spin_lock_irqsave(&iop->state_lock, flags);
> - iop_set_range_uptodate(iop, first, last - first + 1, nr_blocks);
> - if (iop_uptodate_full(iop, nr_blocks))
> - folio_mark_uptodate(folio);
> - spin_unlock_irqrestore(&iop->state_lock, flags);
> + switch (state) {
> + case IOP_STATE_UPDATE:
> + if (!iop) {
> + folio_mark_uptodate(folio);
> + return;
> + }
> + spin_lock_irqsave(&iop->state_lock, flags);
> + iop_set_range_uptodate(iop, first_blk, nr_blks, blks_per_folio);
> + if (iop_uptodate_full(iop, blks_per_folio))
> + folio_mark_uptodate(folio);
> + spin_unlock_irqrestore(&iop->state_lock, flags);
> + break;
> + case IOP_STATE_DIRTY:
> + if (!iop)
> + return;
> + spin_lock_irqsave(&iop->state_lock, flags);
> + iop_set_range_dirty(iop, first_blk, nr_blks, blks_per_folio);
> + spin_unlock_irqrestore(&iop->state_lock, flags);
> + break;
> + }
> }
I can't believe this is what Dave wanted you to do. iomap_iop_set_range()
should be the low-level helper called by iop_set_range_uptodate() and
iop_set_range_dirty(), not the other way around.
next prev parent reply other threads:[~2023-05-04 15:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-04 14:51 [RFCv4 0/3] iomap: Support subpage size dirty tracking to improve write performance Ritesh Harjani (IBM)
2023-05-04 14:51 ` [RFCv4 1/3] iomap: Allocate iop in ->write_begin() early Ritesh Harjani (IBM)
2023-05-04 14:51 ` [RFCv4 2/3] iomap: Change uptodate variable name to state Ritesh Harjani (IBM)
2023-05-04 14:51 ` [RFCv4 3/3] iomap: Support subpage size dirty tracking to improve write performance Ritesh Harjani (IBM)
2023-05-04 15:02 ` Matthew Wilcox [this message]
2023-05-05 3:27 ` Ritesh Harjani
2023-05-05 3:59 ` Matthew Wilcox
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=ZFPJGDqfcUtI4ptO@casper.infradead.org \
--to=willy@infradead.org \
--cc=araherle@in.ibm.com \
--cc=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=disgoel@linux.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
/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.